Re: Merge pgjdbc-parent-poms project into pgjdbc please - Mailing list pgsql-jdbc

On Monday 25 of January 2016 19:27:50 Vitalii Tymchyshyn wrote:
> Пн, 25 січ. 2016 о 08:39 Pavel Raiskup <praiskup@redhat.com> пише:
>
> > On Monday 25 of January 2016 13:17:41 Vitalii Tymchyshyn wrote:
> > > Well, most of enterprise backend servers run on linux. Most are on
> > > commercial, like RedHat or Suse. As of OSGI, it's supported by Fedora
> > (with
> > > Felix packages), it's just not very up to date. And PostgreSQL uses quite
> > > recent features. As I already noted, osgi-enterprise can be replaced with
> > > OPS4J package if there are OSSing problems with org.osgi.
> >
> > ACK here.  There are (or were) people which cared about Felix packages.
> > This might change, but it should not block redistribution of JDBC.  It is
> > really natural to have conditional dependencies.
>
> The problem here is that making some feature optional must be clearly
> stated, preferably in the bundle name.

I'm still not sure about this.  Most of the jar files in distribution do
not have a version in its name -- which is the most important thing to me
as library consumer in any language.  And even this is not that important
in distro packaging to have it in jar name.

> I'd expect postgresql jar taken from Fedora distribution behave the same
> as postgresql jar taken from the official web site. if you change it -
> tell in bold in the description or name it postgresql-no-osgi.jar.

There should be no jar "taken" from Fedora, IMO.  The only supported way
how to use Fedora's jar is to install it via 'yum install
postgresql-jdbc'.  By this you'll get the only one supported jar (version,
feature set) on that particular distribution version.  I probably don't
know what you mean -- you shouldn't download RPMs from web like rpm-find;
that is untrusted source.

The point of having 'jar' file in distribution is to allow other packages
to depend on it, without requiring maven repositories -- to allow other
java packages to connect to PG.  We really don't need to consider OSGi
until it is really supported on Fedora.

> > > Also I suppose other projects are somehow patched because they don't
> > > usually use felix packages.
> >
> > What projects do you mean here?  Maybe we can learn from them, somehow.
>
> E.g. if look here:
> http://mvnrepository.com/artifact/org.hibernate/hibernate-osgi/4.3.5.Final
> you will see hibernate-osgi depends on org.osgi artifact.
> And in Fedora:
> https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/s390/h/hibernate-osgi-4.3.5-6.fc23.noarch.html
> this dependency is provided by felix:
> https://www.rpmfind.net/linux/rpm2html/search.php?query=mvn(org.osgi%3Aorg.osgi.core)

Ouch, that is lot of manual work which - that one could consider mine
field.  Thanks for the reference.

> > > One more thing: as for me it would be confusing to have not
> > > fully-featured driver distributed without being marked somehow.
> >
> > Right, then we can probably discuss how to Linux specific builds somehow.
> > There must be a way?
> > Side note:  Vitalii, as you sort of trust maven repositories, you are fine
> > to use (online) 'maven install', then you'll get a lot of dead code (in
> > fully featured build) on Linux, but anyway -- you are fine.  Some
> > enterprise users however trust Linux distributors and for them can be
> > maven repository insecure.
>
> I don't thy to argue bundling, it's just apple must be apple. If you change
> it - you reflect in the name (see above).

I can not work-around something with bundling.  Bundling is huge security
hole -- usually it is enough to fix one library on Linux system -- but if
you bundle the insecure library into dozens of projects, you are not able
to fix security issues easily.  This is why we 99% of our libraries on the
system only once -- security is the major feature of Fedora.

> And I'd say OSGI problem must be thought globally in OSS, not only for
> PostgreSQL. Basically, as  I see it, current OSGI support is stuck at
> version provided by felix that is outdated (dunno why, may be felix guys
> just switched to org.osgi artifact). That's why a lot of projects dependent
> on it are outdated too (e.g. hibernate noted above is already at 5.0.7,
> 4.3.5 was release in April 2014). And it does not mean OSGI is not used in
> OSS world.

I agree with you that OSGi is the feature that might be needed, but right
now it is stuck.  From distributions POV we can do only one of those:

  1) keep frozen on the old pgjdbc.jar we already provide, backport
     features and security fixes

  2) do lot of hacks: download some third-party SW to allow the build,
     patch osgi support out; (this is basically equivalent to forking the
     project)

  3) stop providing jdbc plugin and force users to depend on maven repo

  4) start providing OSGi solely because of pgjdbc (not enough man-power,
     licensing issues, etc.), missing man-power to work on Felix packages

  5) make the software sanely buildable on linux with limited set of
     prerequisites

So far we combined 1 and 2;  3 is not acceptable;  4 is not possible in
near future; I still believe in 5.
The 2 would be the easiest and cheapest one because all distros are
already doing that;  there is just the need to state that this can be done
consistently in open source linux world.

Pavel