Re: Merge pgjdbc-parent-poms project into pgjdbc please

On Monday 25 of January 2016 19:27:50 Vitalii Tymchyshyn wrote:

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

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