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

Вт, 26 січ. 2016 о 04:32 Pavel Raiskup <praiskup(at)redhat(dot)com> пише:

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

That's what I meant by taken. I must have used wrong word.
Imagine a project bult with maven. And now administrator of the system who
do not belive maven repositories wants to run it with system packages. He
sees that proper versions are there, but it plain does not work and it's
really hard to tell why.
BTW: Why do you think it's not supported? It's supported, but support is
outdated.

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

Why do you think it's for pgjdbc only? I gave you hibernate example. Do you
want more? Check
http://mvnrepository.com/artifact/org.osgi/org.osgi.core/6.0.0/usages and
http://mvnrepository.com/artifact/org.osgi/org.osgi.core/5.0.0/usages
And that's osgi core, not enterpise. And you have problems with that too
because felix version is outdated and more and more projects are going to
be using newer version. You can check enterprise usage:
http://mvnrepository.com/artifact/org.osgi/org.osgi.enterprise/5.0.0/usages The
list is shorter, but it's not about pgjdbc.

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

To do 5, the most sane way is to split postgresql driver into two: the
driver itself and osgi support (or make pgsql-full and pgsql-no-osgi). In
maven artifact should not have functionality that it opted-out in compile
time. It makes artifact stable. If you have different packaging options -
make different artifacts (by name, version or classifier).
But it's a huge change, esp. since historically JDBC drivers are supposed
to be 1 jar.

Best regards, Vitalii Tymchyshyn