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

On Friday 01 of April 2016 10:11:11 Craig Ringer wrote:
> On 22 March 2016 at 19:48, Pavel Raiskup <praiskup@redhat.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.

Yes.  But there is 0% experience with java-comment-preprocessor.

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

Fixed.

> 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.

Then you need to have by-default-excluded files, which are then
by-default-included-by-default-profile.  I can change that, but it looks
like just matter of taste and actual status looks easy enough.

> 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):

I don't think this is the case -- what default profiles could be disabled
unintentionally, or what makes you think so (my maven foo is so weak, I
can miss something obvious)?  I'm not able to control jcp's profiles
explicitly while building the pgjdbc project anyway..

Based on the log, it rather looks like the preprocessor simply ignores the
excpludes we do by maven-compiler-plugin?

> "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."

I'm aware of that -- this basically forced me to use properties for
enabling/disabling profiles (one property can trigger more profiles a
straight forward way).

> 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).

This, for some reason, did not work for me, I'll have a look once more.

> 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.

Thanks!

> 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.

I believe I've read the links before, and the problems you mentioning here
is different, but the status is that this does not help :(.

> 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.

Ok, I need to ping once more on this, while still trying to implement the
opt-out trigger.

> > 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...

Well, I was able to run the testsuite successfully -- so I suspect that
the preprocessor runs fine.  And see below ...

> 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.

I believe you are right here (that maven is equivalent to shell+makefile),
but I'm not yet that good with maven to tell.

> > 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

Well, it look like the preprocessor just ignores our "exclude" statements,
I believe in that because if we simply remove all the java files related
to waffle and osgi, we are able to build the package (== the preprocessor
works).

The question is why jcp ignores the <excludes />.

Pavel