Re: Complicated re-distribution of pgjdbc the "open source way" - Mailing list pgsql-jdbc
| From | Craig Ringer |
|---|---|
| Subject | Re: Complicated re-distribution of pgjdbc the "open source way" |
| Date | |
| Msg-id | CAMsr+YHF36p-d5UTeOxm4XXCr3PS-U4DqE7FTaWFOc=EkNUEmw@mail.gmail.com Whole thread Raw |
| In response to | Re: Complicated re-distribution of pgjdbc the "open source way" (Vitalii Tymchyshyn <vit@tym.im>) |
| Responses |
Re: Complicated re-distribution of pgjdbc the "open source way"
(Craig Ringer <craig@2ndquadrant.com>)
|
| List | pgsql-jdbc |
On 8 March 2016 at 21:18, Vitalii Tymchyshyn <vit@tym.im> wrote:
> And for me it's not a reason to make some useful feature optional
> complicating things for a user (instead of per-JDK jar you are starting
> to produce at least twice as many jars to deal with).
I need to react because of this ^. PostgreSQL server has a lot of
features available during build, try './configure --help'. You can choose
what features are important for you, and what not.
The opt-out (unused by upstream probably) in pgjdbc I would like to see is
far from being that sophisticated. What is the problem with this?It's not build sophistication, it's usage sophistication. JDBC drivers are built as one jar. There are a lot of tools you just need to give a driver jar. So modularization is not really an option. And making tons of different kinds of jars needs to be really important to be justified.And most of the java world do not build, it takes jar from repository. Thats why compile-time optional features are not popular. This is handled runtime. Modularization is also popular, but it's not an option for JDBC driver.
I don't mind making it compile-time optional in this case. I did so, IIRC, for the original Ant build. It's simply omitting some dependencies and not building a file or two. It produces a thinner jar, which some people will care about even aside from Fedora's issues.
I originally intended it to be necessary to add the Waffle stuff to the CLASSPATH yourself if you wanted to use SSPI with JNA, and originally documented that as being the case. Support is still *compiled*, just I don't have a problem with it being that way, but that won't satisfy Fedora, because for them it's objectionable that the support is even compiled, as it requires waffle-jna (not in fedora) to exist temporararily in the build classpath. They're going to have to skip compilation of the Java files that use it in PgJDBC its self too, so that means build profiles.
It shouldn't be hard. They just can't expect to cut the features that upset them out unconditionally.
That said, I don't know about the OSGi stuff. I don't touch OSGi, I escaped the Java world around when it became nearly unavoidable.
Note the whole Java world probably. I, for example, can consider myself
as somebody somebody who needs to write some gui app in Java, than
distribute that as native package for distributions. More! I want the
distribution guys do it for myself.
So ... about 0.00001% of the Java world :p
You'll *rapidly* run into a wall of missing libraries if you attempt to package anything except toy apps, or ones that happen to closely conform to something (like Eclipse) that there's been a massive distro effort to get packaged. Any practical 3rd-party-distributed app will bundle many of its dependency jars. Especially since what's in RHEL6/RHEL7 will usually be too old to use for the app anyway.
That said, I do agree with you that PgJDBC should be one of the available packages, JDBC drivers are pretty core functionality. It has a more stable interface than many libraries, partly due to the JDBC spec its self, and it's a general purpose connector tool that users kind of expect to have around.
I can't speak for everyone else here, but I'd like to make sure you can continue to package PgJDBC. Just not by ripping bits you don't like out unconditionally.
> Guys, you really need to decide with OSG in general. How are you going> to deal with modern versions of containers like JBoss that has OSGi as a
> core feature? That is the problem.
JBoss is not Fedora. We can't pull everything into Fedora just because we
want to connect 'A with B' where both 'A' and 'B' are already there and we
are fine with that. To connect 'A' with 'B' is needed 'C (osgi support)'
and 'D (waffle)', where we are not able to provide 'D' and 'C' is not
needed atm (somebody tried to deal with that in Y2012, and we did not move
forward yet in 2016). We need solution now, and we can enable things
later.JBoss was just an example. I should stop giving you examples because you focus on them. JBoss is like Hibernate just an example of major software you should be dealing with. Most enterprise containers support OSGi.
JBoss is a good example, though, especially since it's Maven-based.
As for OSGi ... I agree that that's a broader problem than PgJDBC, but I don't really care if Fedora omit support for it in the Fedora-built driver. If they can supply a build patch to do it in a non-ugly way I don't object to merging it either. It'll result in some degree of user confusion if people pick up the Fedora-built JAR and try to distribute it or use it elsewhere, but frankly, they won't. It'll get used for packaged apps, and only packaged apps. Everyone else will just download the JAR like usual. So I don't even think we need to push for some kind of differentiation to indicate it's a limited-features rebuild.
I wouldn't even overly object to a driver split into pgjdbc-core and pgjdbc, where pgjdbc-core is a zero-dependencies (or rather, slf4j-only) component that pgjdbc depends on and bundles. It'd help avert future dramas of this sort and wouldn't be especially ugly. Of course that'd have to come with a pull request that passes the tests....
pgsql-jdbc by date: