Re: Complicated re-distribution of pgjdbc the "open source way"
| От | Craig Ringer |
|---|---|
| Тема | Re: Complicated re-distribution of pgjdbc the "open source way" |
| Дата | |
| Msg-id | CAMsr+YFvjAeD_op6cKUJ+MmwfEWAM_tACAE7is=ELx7nKX3JZw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Complicated re-distribution of pgjdbc the "open source way" (Pavel Raiskup <praiskup@redhat.com>) |
| Ответы |
Re: Complicated re-distribution of pgjdbc the "open source way"
(Pavel Raiskup <praiskup@redhat.com>)
|
| Список | pgsql-jdbc |
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.
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:
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
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Craig RingerДата:
Сообщение: Re: Complicated re-distribution of pgjdbc the "open source way"
Следующее
От: Pavel RaiskupДата:
Сообщение: Re: Complicated re-distribution of pgjdbc the "open source way"