Re: Complicated re-distribution of pgjdbc the "open source way"

On 22 March 2016 at 19:48, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:

> https://github.com/praiskup/pgjdbc/commits/pgjdbc-linux-fixes

Thanks for proceeding with this. I hope you've been able to get some help
from Maven folks within RH.

I've made some comments on the commit. Most notably you're exclusing
ISSPIClient.java from the build.

Note that the patches are not final and are somehow destructive, which is
> definitely not on schedule for upstream proposal -- I just need to present
> where I feel blocked.
>

Totally fine, thanks for making the effort.

> -DwaffleEnabled=false

OK, so the profile activation of excludeWaffleFiles is controlled by
the waffleEnabled property being false, in which case you exclude the SSPI
files.

I personally wonder if it should be an enabled-by-default profile that
*includes* SSPI files and dependencies, which you can disable to turn SSPI
support off. But that shouldn't really matter.

I suspect that what's happening here is that when the excludeWaffleFiles
profile is activated, other profiles get deactivated - specifically,
activeByDefault profiles. Per the docs (
http://maven.apache.org/guides/introduction/introduction-to-profiles.html):

"This [<activeByDefault/>] profile will automatically be active for all
builds unless another profile in the same POM is activated using one of the
previously described methods. All profiles that are active by default are
automatically deactivated when a profile in the POM is activated on the
command line or through its activation config."

You can use "mvn help:active-profiles --batch-mode --offline
-DwaffleEnabled=false" to see which profiles are activated and compare that
to "mvn help:active-profiles --batch-mode --offline" (without the extra
system property).

I'm afraid my Maven's very rusty these days and I wasn't involved in the
final PgJDBC ant-to-maven conversion, though I agreed it was a good idea.
I'll try to help.

Starting with:

* http://stackoverflow.com/q/5309379/398670
* http://greyfocus.com/2015/06/activebydefault-maven-other-profiles/

You could use an <activeProfiles/> in ~/.m2/settings.xml, an explicit -P
argument on the command line, or make the profile activated dependent on
the absence of a property that we never set so it's always active.

I have to say that I've always thought the way <activeByDefault/> has no
option to suppress automatic deactivation when another profile is activated
is a real wart. You should be able to declare a profile that's always
active unless explicitly deactivated by a negated argument to -P more
cleanly. As it is you need a hacky workaround.

IIRC in my own projects I used to avoid activeByDefault profiles and I'd
specify profile-lists in different settings.xml configurations. While
getting quite annoyed.

http://stackoverflow.com/a/2248552/398670 and
http://stackoverflow.com/q/2246033/398670 explain in more detail. IMO it's
a real wart in the build system. You're getting bitten by it because you're
adding build profiles to a codebase that didn't use them before.

When using those changes -- after the parent-poms is built and installed
> into ~/.m2, after some dependencies for osgi are installed from maven (I'm
> not yet ready to fully avoid osgi code - starting with waffle as you said)
>

Sensible. TBH I suspect RH will need to get OSGi into RH proper soon
anyway, since it is IIRC needed for major things like Glassfish, JBoss AS
7, etc.

> This fails with:
> [ERROR] Failed to execute goal com.igormaznitsa:jcp:6.0.1:preprocess
> (preprocessSources) on project postgresql: Can't find a source directory
>
> [/home/praiskup/rh/projects/pgjdbc/pgjdbc/target/generated-sources/annotations]
>

Looks like the annotation preprocessor didn't run so there's no input,
suggesting it's possibly controlled by an <activeByDefault/> profile.
Hopefully not in a 3rd party POM...

The error log is attached. Seems like something wrong is with
> preprocessor.

> It is quite exhausting and
> I start to think that, if we want to have it upstream, we need to have a
> shell script or Makefile (that would be is more flexible)

It's not more flexible, it's just more *familiar*. When I moved from Java
to C dev I used to think "gah, I wish I could just do this with maven, this
makefile is AWFUL".

Maven's pretty much arbitrarily programmable. The problem is that it's done
in an undeniably awkward way, where complicated stuff requires the
implementation of a maven plugin to do what you want. I doubt that's
necessary in this case though. Thankfully.

I do think maven has some massive warts, but I've spent long enough
swearing at makefiles, at CMake, at SCons (back in the day), at Ant and at
autoconf to think that all build systems are pretty much awful. It's just
you're more used to make's awfulness.

> sure whether that will be friendly with igormaznitsa:jcp thing.
>

I wasn't aware that the Maven build conversion of PgJDBC used jcp. I'm a
little surprised it was necessary, but we do have to support multiple
different JDBC spec versions, which creates some complexities.

It's probably not going to be a major barrier. The issue you seem to have
hit here is that the annotation processor didn't run so when when jcp tried
to

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services