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

On 8 March 2016 at 21:18, Vitalii Tymchyshyn <vit(at)tym(dot)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.

https://fedoraproject.org/wiki/JBossAS7

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

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