Обсуждение: Merge pgjdbc-parent-poms project into pgjdbc please

Hi all,

could we consider $Subject?  To build from source 'pgdjbc', we would need
release tarball of 'pgjdbc-parent-poms'.  I can generate one from git, but
that has very similar issues as issues in pgjdbc release process discussed
in parallel thread.

I do not complain, I'm just not sure what is the benefit of having this as
separate project (and merging would terribly simplify things).

Are there other projects using pgjdbc-parent-poms?

Pavel

On Jan 24, 2016 3:44 AM, "Pavel Raiskup" <praiskup@redhat.com> wrote:
>
> Hi all,
>
> could we consider $Subject?  To build from source 'pgdjbc', we would need
> release tarball of 'pgjdbc-parent-poms'.  I can generate one from git, but
> that has very similar issues as issues in pgjdbc release process discussed
> in parallel thread.

Well they are there for a reason. The project generates 3 artifacts. A jar for j6,
J7, and j8. I imagine you are only going to generate 1 of those.

Others may want a different one

We can include them in the tar file.
> I do not complain, I'm just not sure what is the benefit of having this as
> separate project (and merging would terribly simplify things).
>
> Are there other projects using pgjdbc-parent-poms?
Doubtful

Dave

> Pavel
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

Pavel> Are there other projects using pgjdbc-parent-poms?

Technically speaking, when building a Maven project, you need to have
full set of parent dependencies.
In other words, you have to have pgjdbc-parent-poms to know all
dependencies of pgjdbc.

Each and every project that uses pgjdbc, has to use pgjdbc-parent-poms
in one way or another.

pgjdbc-parent-poms is there to isolate common configuration parts and
enable it's own release schedule for that common part.
Ideally, pgjdbc-parent-poms releases should be very rare.


The main point of having parent-poms sepate is to share code between
java6, java7, and java8 build scripts.
We cannot release the same artifactid+version combo multiple times,
thus we have a dedicated "parent pom" configuration.

We cannot merge all the jre6, jre7, jre8 to a single project due to
maven's limitation: it would result in a case when you release
multiple versions of the same artifact id at once.
It is just not supported by Maven's default release procedure.

We cannot use Maven's classifiers as they break source.jar &
javadoc.jar integration in IDEs.

Dave> We can include them in the tar file.

That is a tricky question. "parent-poms" is a pgjdbc's internal
workaround for a specific Maven problem.
The only sane way of including "parent-poms" into a "main" tar file
would be such a way that would transparently work when building pgjdbc
as usual.

In other words: download tarball, untar, `mvn install` (just once).
If additional steps required, I think it is better to have a separate
tar for parent poms.

Vladimir

On Sunday 24 of January 2016 16:29:15 Vladimir Sitnikov wrote:
> Pavel> Are there other projects using pgjdbc-parent-poms?
>
> Technically speaking, when building a Maven project, you need to have
> full set of parent dependencies.
> In other words, you have to have pgjdbc-parent-poms to know all
> dependencies of pgjdbc.
>
> Each and every project that uses pgjdbc, has to use pgjdbc-parent-poms
> in one way or another.

So far I understand the dependencies.  I just just don't understand the
separation of those two projects.

The rest of the mail I'm not able parse :( probably due to missing
background.  I must admit that it all sounds terribly complicated process
to build pgjdbc from source (taking into account how trivial is to build
so complicated project like PostgreSQL server itself).

Maybe there should be some more precise HOWTO build from source in
README.md in future :).

So, to the failing build logs recently requested, so far I ended up here:

https://copr-be.cloud.fedoraproject.org/results/praiskup/postgresql-jdbc-rel-9.4.1207plus/fedora-rawhide-x86_64/00155455-postgresql-jdbc/build.log.gz
Can anybody help me?  I am expected to install postgresql-parent-poms, I
see -- but can I have the parent-poms installed somehow locally -- without
creating a new system package?

Pavel

> pgjdbc-parent-poms is there to isolate common configuration parts and
> enable it's own release schedule for that common part.
> Ideally, pgjdbc-parent-poms releases should be very rare.
>
>
> The main point of having parent-poms sepate is to share code between
> java6, java7, and java8 build scripts.
> We cannot release the same artifactid+version combo multiple times,
> thus we have a dedicated "parent pom" configuration.
>
> We cannot merge all the jre6, jre7, jre8 to a single project due to
> maven's limitation: it would result in a case when you release
> multiple versions of the same artifact id at once.
> It is just not supported by Maven's default release procedure.
>
> We cannot use Maven's classifiers as they break source.jar &
> javadoc.jar integration in IDEs.
>
> Dave> We can include them in the tar file.
>
> That is a tricky question. "parent-poms" is a pgjdbc's internal
> workaround for a specific Maven problem.
> The only sane way of including "parent-poms" into a "main" tar file
> would be such a way that would transparently work when building pgjdbc
> as usual.
>
> In other words: download tarball, untar, `mvn install` (just once).
> If additional steps required, I think it is better to have a separate
> tar for parent poms.
>
> Vladimir

Pavel>I must admit that it all sounds terribly complicated process
Pavel>to build pgjdbc from source

I must admit you exaggerate here.

Building pgjdbc is **just** a single `mvn install` command.
As you miss pgjdbc-parent-poms (it is your choice to miss it in the
first place), you need to get pgjdbc-parent-poms sources, then `mvn
install` it.
pgjdbc-parent-poms are at GitHub's releases page (see [1])

Is is that complicated?

Pavel> can I have the parent-poms installed somehow locally -- without
Pavel>creating a new system package?

I'm not sure if end-user applications would work if you skip packaging
of pgjdbc-parent-poms.
To install pgjdbc-parent-poms locally, see [2].

Pavel> taking into account how trivial is to build
Pavel>so complicated project like PostgreSQL server itself

It is like a single command that works in all the supported operation
systems and downloads all the dependencies?
I'm afraid, it is not.

[1]: https://github.com/pgjdbc/pgjdbc-parent-poms/releases
[2]: https://github.com/pgjdbc/pgjdbc-parent-poms#installing-parent-poms-to-local-repository

Vladimir

Álvaro>- What if, for instance, the jre6 version wants to use a
different version of a given dependency?

It will just override the version.
However, the idea is to keep versions the same as much as it is possible.

Álvaro>- What does it mean for pgjdbc/ubenchmark project to "know"
about waffle or osgi dependencies?

It means that we can benchmark exactly the libraries that are in the
dependencies of the main project.
How otherwise would you pick a waffle version in case you want to benchmark it?

Álvaro> is not uncommon to see dependencies having different versions
for Java <=6 and Java > 6)

The idea is "current setup" is "good enough", so we would drop Java 6
support earlier than such "specific for Java 6 dependency" appears.

Vladimir

On 24/01/16 19:23, Vladimir Sitnikov wrote:
> Álvaro>- What if, for instance, the jre6 version wants to use a
> different version of a given dependency?
>
> It will just override the version.
     Sure, it can be overridden. But let me put it in a different way:
to me, this is kind of a leaking abstraction. We're putting on the
parent stuff that the parent should not know about (like an osgi or
waffle dependency). Really, dependencies on a global parent pom (even if
on dependencyManagenemt, which is where they belong) are only for those
things so common that you surely want to use them all the time. waffle,
osgi, do not fit in this category. Logging or findbugs may, for instance.

> However, the idea is to keep versions the same as much as it is possible.

     That's desirable, but not always possible.
>
> Álvaro>- What does it mean for pgjdbc/ubenchmark project to "know"
> about waffle or osgi dependencies?
>
> It means that we can benchmark exactly the libraries that are in the
> dependencies of the main project.
> How otherwise would you pick a waffle version in case you want to benchmark it?

     Sure, if the benchmark wants to benchmark waffle, then it must of
course include that dependency. But today is not doing that, and that's
why it should not have that dependency.
>
> Álvaro> is not uncommon to see dependencies having different versions
> for Java <=6 and Java > 6)
>
> The idea is "current setup" is "good enough", so we would drop Java 6
> support earlier than such "specific for Java 6 dependency" appears.

     I think current setup is great. It's just that the dependencies
declared in the parent pom, in my opinion, should be in their individual
projects.

     Cheers,

     Álvaro

Pavel, would you post another build log as you add parent-poms build/package?

I've poked around copr.fedorainfracloud.org a bit, and it looks like
it can fetch "rpm build script" from git and copr can be triggered via
webhook.

This means we can setup GitHub to trigger a copr build on new commits.
The *.spec file in question might live in the main pgjdbc repository,
or in a side one.

There seem to be a copr-cli client interface, thus we might be able to
trigger a copr build from within Travis job.

What I do not like is "project" in copr seems to bind to a specific person.
Is there a way to create copr account for pgjdbc community, so the
copr job can be managed by multiple developers?

Vladimir

On Sunday 24 of January 2016 23:55:22 Vladimir Sitnikov wrote:
> Pavel, would you post another build log as you add parent-poms
> build/package?

I'll send you soon the build logs, I do not plan to add parent-poms as
separate fedora package (separate spec file) -- it does not make sense,
the package would be used just by jdbc plugin during build (and additional
bureaucracy would be worthless).  I'll rather make the package build-able
in 2 phases.

> I've poked around copr.fedorainfracloud.org a bit, and it looks like
> it can fetch "rpm build script" from git and copr can be triggered via
> webhook.
> This means we can setup GitHub to trigger a copr build on new commits.

Right, that is the "CI" I talked about.

> The *.spec file in question might live in the main pgjdbc repository,
> or in a side one.

Wow, having this in upstream repo would be perfect.

> There seem to be a copr-cli client interface, thus we might be able to
> trigger a copr build from within Travis job.

Right, that is possible too, but I'm not sure how to create "pseudo-user";
copr-cli is usually run by real user's credentials -- so if you don't mind
it is OK.  I'll check; but the webhook would be better.

> What I do not like is "project" in copr seems to bind to a specific person.
> Is there a way to create copr account for pgjdbc community, so the
> copr job can be managed by multiple developers?

For this you need to have new Fedora group.  I'll try to request one
called like @pgjdbc -- but to allow you to access that group in Copr,
you'll need to have fedora account (FAS).

Pavel

Pavel>copr-cli is usually run by real user's credentials -- so if you don't mind

Travis allows to secure variables, so this should be fine.

Pavel>I'll try to request one
Pavel>called like @pgjdbc -- but to allow you to access that group in Copr,

That would be great.

Pavel>you'll need to have fedora account (FAS).

I think that is bearable.

Vladimir

On Monday 25 of January 2016 11:53:07 Vladimir Sitnikov wrote:
> Pavel>I'll try to request one
> Pavel>called like @pgjdbc -- but to allow you to access that group in Copr,
>
> That would be great.

I do not have your FAS nick yet to add you to @pgjdbc-sig -- we'll need to
handle your nick later, once group is created:
https://fedorahosted.org/fedora-infrastructure/ticket/5072

Pavel

Pavel> I do not have your FAS nick yet

I'm https://copr.fedorainfracloud.org/coprs/vladimirsitnikov/

Vladimir

On Sunday 24 of January 2016 23:55:22 Vladimir Sitnikov wrote:
> Pavel, would you post another build log as you add parent-poms
> build/package?

The first phase (build of parent-poms) fails:

https://copr-be.cloud.fedoraproject.org/results/praiskup/postgresql-jdbc-rel-9.4.1207plus/fedora-rawhide-x86_64/00155599-postgresql-jdbc/build.log.gz

Fails on missing osgi.enterprise dependency, as Vitalii mentioned -- we
could switch to felix alternative.  What is the consensus on this?

Pavel

> I've poked around copr.fedorainfracloud.org a bit, and it looks like
> it can fetch "rpm build script" from git and copr can be triggered via
> webhook.
>
> This means we can setup GitHub to trigger a copr build on new commits.
> The *.spec file in question might live in the main pgjdbc repository,
> or in a side one.
>
> There seem to be a copr-cli client interface, thus we might be able to
> trigger a copr build from within Travis job.
>
> What I do not like is "project" in copr seems to bind to a specific person.
> Is there a way to create copr account for pgjdbc community, so the
> copr job can be managed by multiple developers?
>
> Vladimir

Pavel>What is the consensus on this?

I'm not osgi expert, however, I think "Felix" does not solve the problem.
"osgi.enterprise" is a set of interfaces that are defined by OSGi
specification, thus Felix does not include it.

Thus the solution is to add one more build step: download relevant
sources, build them.
Even though there's no build script, it should be rather simple to
reconstruct. The source files are available in [1]
The license is "Apache 2".

Is it feasible? Where's the build file should be located?
I guess it should be somewhere close to the *.spec.

[1]: http://central.maven.org/maven2/org/osgi/org.osgi.enterprise/5.0.0

Vladimir

On Monday 25 of January 2016 14:27:46 Vladimir Sitnikov wrote:
> Pavel>What is the consensus on this?
>
> I'm not osgi expert, however, I think "Felix" does not solve the problem.
> "osgi.enterprise" is a set of interfaces that are defined by OSGi
> specification, thus Felix does not include it.

I'm not expert too.

> Thus the solution is to add one more build step: download relevant
> sources, build them.
> Even though there's no build script, it should be rather simple to
> reconstruct. The source files are available in [1]
> The license is "Apache 2".
>
> Is it feasible? Where's the build file should be located?
> I guess it should be somewhere close to the *.spec.
>
> [1]: http://central.maven.org/maven2/org/osgi/org.osgi.enterprise/5.0.0

It is imo not feasible;  there is no demand for that package in Linux, is
that right?

Seriously -- adding new package makes sense only if it is going to be
_used_, it is nontrivial action, nontrivial amount of time to do
maintenance and adopt upstream changes, etc -- just to build connector
between PostgreSQL and Java.

These situations have usually clear answer:  Optional build dependency.
Something which your build/runtime depends only if it is feasible for
targeted platform which Fedora is not.

Pavel

On Monday 25 of January 2016 12:39:52 Pavel Raiskup wrote:
> These situations have usually clear answer:  Optional build dependency.
> Something which your build/runtime depends only if it is feasible for
> targeted platform which Fedora is not.

Of course, to be clear about this -- nobody is going to download XX distro
RPM to use the packaged '*.jar' on Windows.  There are different channels.

Be sure that *our* RPMs are used *only* on particular version of Fedora.
That's why e.g. PostgreSQL built for Fedora does not have to have compiled
Windows support in (even though PostgreSQL works on Windows too, you just
have to download it from somewhere else).

Pavel

Pavel>   there is no demand for that package in Linux

Pease, read again:
Vladimir>add one more build step: download relevant
Vladimir>sources, build them

Where do you see "adding new package" there?

Pavel>if it is feasible for
Pavel>targeted platform which Fedora is not.

For instance: OpenHAB uses OSGi extensively. It would not able to use
pgjdbc "without OSGi".

Vladimir

Pavel> Of course, to be clear about this -- nobody is going to
download XX distro
Pavel>RPM to use the packaged '*.jar' on Windows.  There are different channels

Please clarify my "OpenHAB" example.
"pgjdbc without OSGi metadata" is of no use for OpenHAB.
OSGi is not Windows-specific.

Vladimir

On Monday 25 of January 2016 14:48:36 Vladimir Sitnikov wrote:
> Pavel> Of course, to be clear about this -- nobody is going to
> download XX distro
> Pavel>RPM to use the packaged '*.jar' on Windows.  There are different channels
>
> Please clarify my "OpenHAB" example.  "pgjdbc without OSGi metadata" is
> of no use for OpenHAB.  OSGi is not Windows-specific.

Are they using OSGi enterprise somehow on Linux?  Why would OpenHAB guys
need OSGi compiled in pgjdbc.jar provided by RPMs?  Why OpenHAB needs us
to compile OSGi in?

IOW: As far as I'm concerned, there is no request for OSGi enterprise on
linux.

Pavel

On Monday 25 of January 2016 14:46:14 Vladimir Sitnikov wrote:
> Pavel>   there is no demand for that package in Linux
>
> Pease, read again:
> Vladimir>add one more build step: download relevant
> Vladimir>sources, build them
>
> Where do you see "adding new package" there?

Right, I missed that, sorry.  But this requires new package -- it is new
upstream, new license -- I do not want to cross the border of
"good packagers group"..

pgjdbc-parent-poms are (probably) fine, because it is the same upstream as
pgjdbc, has the same license -- and to be honest, I guess those two git
repositories will be merged into one git and tarball in future anyway.  If
not, pgjdbc main repo could be made self-standing sooner or later.

And similarly to osgi stuff, there is no demand for the separate package
existence.

Pavel

On Monday 25 of January 2016 13:07:09 Pavel Raiskup wrote:
> On Monday 25 of January 2016 14:46:14 Vladimir Sitnikov wrote:
> > Pavel>   there is no demand for that package in Linux
> >
> > Pease, read again:
> > Vladimir>add one more build step: download relevant
> > Vladimir>sources, build them
> >
> > Where do you see "adding new package" there?
>
> Right, I missed that, sorry.  But this requires new package -- it is new
> upstream, new license -- I do not want to cross the border of
> "good packagers group"..
>
> pgjdbc-parent-poms are (probably) fine, because it is the same upstream as
> pgjdbc, has the same license -- and to be honest, I guess those two git
> repositories will be merged into one git and tarball in future anyway.  If
> not, pgjdbc main repo could be made self-standing sooner or later.
>
> And similarly to osgi stuff, there is no demand for the separate package
> existence.

I also don't see the primary source -- is this osgi.enterprise code
expected to be freely redistributed?  Even if yes, I'm against taking the
packaging responsibilities on our database-team.  Nobody else needs it and
we are not the right people to take care about it :(

Pavel

Pavel>I also don't see the primary source -- is this osgi.enterprise code
Pavel>expected to be freely redistributed?

I am not going to redistribute it.
Are you?

I suggest just use the existing sources (that are available at Maven Central).

Pavel>Are they using OSGi enterprise somehow on Linux?

They use OSGi, they run on Linux somehow => they are using OSGI on
Linux somehow.

Pavel> OSGi compiled in pgjdbc.jar provided by RPMs?

OSGi allows to isolate services and providers. OpenHAB project has
chosen OSGi for dependency management, thus they rely on database
services that OSGi provides.
Someone choses *.rpm, someone choses *.deb. Same thing here: someone
choses OSGi to manage dependencies & components & services.

Pavel>Why OpenHAB needs us
Pavel>to compile OSGi in?

osgi-enabled pgjdbc.jar is useful for applications that rely on OSGi.
non-osgi-enabled pgjdbc.jar is useless for those kind of applications.

Vladimir

On Monday 25 of January 2016 07:43:25 Dave Cramer wrote:
> On 25 January 2016 at 07:02, Pavel Raiskup <praiskup@redhat.com> wrote:
>
> > On Monday 25 of January 2016 14:48:36 Vladimir Sitnikov wrote:
> > > Pavel> Of course, to be clear about this -- nobody is going to
> > > download XX distro
> > > Pavel>RPM to use the packaged '*.jar' on Windows.  There are different
> > channels
> > >
> > > Please clarify my "OpenHAB" example.  "pgjdbc without OSGi metadata" is
> > > of no use for OpenHAB.  OSGi is not Windows-specific.
> >
> > Are they using OSGi enterprise somehow on Linux?  Why would OpenHAB guys
> > need OSGi compiled in pgjdbc.jar provided by RPMs?  Why OpenHAB needs us
> > to compile OSGi in?
> >
> > IOW: As far as I'm concerned, there is no request for OSGi enterprise on
> > linux.
>
> ?? osgi is not a windows specific technology.

Right, but that is orthogonal issue -- nobody else needs it on Fedora.  We
are taking care of databases stuff and thus we don't have enough resources
to maintain whole OSGi to bring this into Fedora.

I haven't found this packaged for other Linux/FreeBSD distros, so probably
nobody needs it there.  Again, this is not that much important --
packaging is possible, we in DB team are not able to do it.

Pavel

On Monday 25 of January 2016 15:50:33 Vladimir Sitnikov wrote:
> Pavel>I also don't see the primary source -- is this osgi.enterprise code
> Pavel>expected to be freely redistributed?
>
> I am not going to redistribute it.
> Are you?

That is exactly what I do not want ;).

> I suggest just use the existing sources (that are available at Maven
> Central).

How?

> Pavel>Are they using OSGi enterprise somehow on Linux?

> They use OSGi, they run on Linux somehow => they are using OSGI on Linux
> somehow.

This is important question -- do they require maven?  If yes, it is
orthogonal set of issues.

> Pavel> OSGi compiled in pgjdbc.jar provided by RPMs?
>
> OSGi allows to isolate services and providers. OpenHAB project has
> chosen OSGi for dependency management, thus they rely on database
> services that OSGi provides.
> Someone choses *.rpm, someone choses *.deb. Same thing here: someone
> choses OSGi to manage dependencies & components & services.

Sounds like RPMs should not depend on OSGi, same as OSGi does not depend
on RPMs.

> Pavel>Why OpenHAB needs us
> Pavel>to compile OSGi in?
>
> osgi-enabled pgjdbc.jar is useful for applications that rely on OSGi.
> non-osgi-enabled pgjdbc.jar is useless for those kind of applications.

But OSGi is not on our platform, at least at this time.  So how can they
use jar from our RPMs?

Pavel

Pavel> nobody else needs it on Fedora

How do you know that?

pgjdbc/src/main/java/org/postgresql/osgi/PGDataSourceFactory.java is
one of the public end-points for pgjdbc.
What you are saying is just: "nobody cares OSGi".
Google gives 800K results for OSGi. Stack overflow gives 15K. It is
not that wise to just drop OSGi.

Vladimir>>xisting sources (that are available at Maven
Vladimir>> Central).

Pavel>How?

wget https://search.maven.org/remotecontent?filepath=org/osgi/org.osgi.enterprise/5.0.0/org.osgi.enterprise-5.0.0.jar

Pavel>This is important question -- do they require maven?

I think they do. Their source repository is full of pom.xml files.

Pavel> So how can they use jar from our RPMs?

What is the purpose of packaging pgjdbc.jar into RPM then if jar files
are not "accessible"?

Vladimir

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.
Also I suppose other projects are somehow patched because they don't usually use felix packages.
One more thing: as for me it would be confusing to have not fully-featured driver distributed without being marked somehow. E.g. user trying to use it would be surprised why osgi datasource registration does not work in some environment.

Best regards, Vitalii Tymchyshyn

On Monday 25 of January 2016 16:08:36 Vladimir Sitnikov wrote:
> Pavel> nobody else needs it on Fedora
>
> How do you know that?

Because it is not packaged yet.  If it is used on Linux, then through
maven.  But we don't need to take care of that usecases.

Our usecase is that you even don't need maven to _run_ (not build) jdbc
Fedora.  It has been always like that -- see the jdbc plugin spec file how
old is it, it used to build with ant.

At this moment -- all you need to access PostgreSQL server is to install
Java and pgjdbc driver and you can access remote running PostgreSQL
server.

> pgjdbc/src/main/java/org/postgresql/osgi/PGDataSourceFactory.java is
> one of the public end-points for pgjdbc.
> What you are saying is just: "nobody cares OSGi".
> Google gives 800K results for OSGi. Stack overflow gives 15K. It is
> not that wise to just drop OSGi.
>
> Vladimir>>xisting sources (that are available at Maven
> Vladimir>> Central).
>
> Pavel>How?
>
> wget https://search.maven.org/remotecontent?filepath=org/osgi/org.osgi.enterprise/5.0.0/org.osgi.enterprise-5.0.0.jar

This is not acceptable, unfortunately.  That jar is not aimed for
re-distribution, we can't depend on it.

> Pavel>This is important question -- do they require maven?
>
> I think they do. Their source repository is full of pom.xml files.

Then they don't use Linux RPMs and they don't need us to provide the OSGi
support.

> Pavel> So how can they use jar from our RPMs?
>
> What is the purpose of packaging pgjdbc.jar into RPM then if jar files
> are not "accessible"?

They are accessible, but even if they are -- OpenHAB guys don't use them
most probably.  They still use the upstream one from maven.

Pavel

Pavel>This is not acceptable, unfortunately.

Rrrr.
Of course I mean source.jar.

wget
http://search.maven.org/remotecontent?filepath=org/osgi/org.osgi.enterprise/5.0.0/org.osgi.enterprise-5.0.0-sources.jar
unzip org.osgi.enterprise-5.0.0-sources.jar
cd ...
mvn install

Would you please look into org.osgi.enterprise-5.0.0-sources.jar at
least once before you say "is not acceptable" one more time?

Pavel>Because it is not packaged yet.  If it is used on Linux, then through
Pavel>maven.  But we don't need to take care of that usecases.

Pavel> Then they don't use Linux RPMs a

It is chicken-and-egg problem. No OSGi support in RPMs => projects
chose "redistribute all the required jar files" and ignore PRMs =>
RPMs do not get better.

So the question is what is the purpose of pgjdbc.jar.rpm if everybody
redistributes the jar?


Vladimir

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.

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

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

Pavel

> E.g. user trying to use it would be surprised why osgi datasource
> registration does not work in some environment.
>
> Best regards, Vitalii Tymchyshyn
>
> Пн, 25 січ. 2016 07:55 Pavel Raiskup <praiskup@redhat.com> пише:
>
> > On Monday 25 of January 2016 15:50:33 Vladimir Sitnikov wrote:
> > > Pavel>I also don't see the primary source -- is this osgi.enterprise code
> > > Pavel>expected to be freely redistributed?
> > >
> > > I am not going to redistribute it.
> > > Are you?
> >
> > That is exactly what I do not want ;).
> >
> > > I suggest just use the existing sources (that are available at Maven
> > > Central).
> >
> > How?
> >
> > > Pavel>Are they using OSGi enterprise somehow on Linux?
> >
> > > They use OSGi, they run on Linux somehow => they are using OSGI on Linux
> > > somehow.
> >
> > This is important question -- do they require maven?  If yes, it is
> > orthogonal set of issues.
> >
> > > Pavel> OSGi compiled in pgjdbc.jar provided by RPMs?
> > >
> > > OSGi allows to isolate services and providers. OpenHAB project has
> > > chosen OSGi for dependency management, thus they rely on database
> > > services that OSGi provides.
> > > Someone choses *.rpm, someone choses *.deb. Same thing here: someone
> > > choses OSGi to manage dependencies & components & services.
> >
> > Sounds like RPMs should not depend on OSGi, same as OSGi does not depend
> > on RPMs.
> >
> > > Pavel>Why OpenHAB needs us
> > > Pavel>to compile OSGi in?
> > >
> > > osgi-enabled pgjdbc.jar is useful for applications that rely on OSGi.
> > > non-osgi-enabled pgjdbc.jar is useless for those kind of applications.
> >
> > But OSGi is not on our platform, at least at this time.  So how can they
> > use jar from our RPMs?
> >
> > Pavel
> >
> >

On Monday 25 of January 2016 16:37:56 Vladimir Sitnikov wrote:
> Pavel>This is not acceptable, unfortunately.
>
> Rrrr.
> Of course I mean source.jar.
>
> wget
http://search.maven.org/remotecontent?filepath=org/osgi/org.osgi.enterprise/5.0.0/org.osgi.enterprise-5.0.0-sources.jar
> unzip org.osgi.enterprise-5.0.0-sources.jar
> cd ...
> mvn install

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.066 s
[INFO] Finished at: 2016-01-25T14:42:35+01:00
[INFO] Final Memory: 5M/117M
[INFO] ------------------------------------------------------------------------
[ERROR] The goal you specified requires a project to execute but there is no POM in this directory (/tmp/osgi). Please
verifyyou invoked Maven from the correct directory. -> [Help 1] 
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException

> Would you please look into org.osgi.enterprise-5.0.0-sources.jar at
> least once before you say "is not acceptable" one more time?

I've done so.  This is probably build product, not the original
tarball/zipfile to build from.  Even if it was, this is way to hell -- we
can't bundle stuff like that.

> Pavel>Because it is not packaged yet.  If it is used on Linux, then through
> Pavel>maven.  But we don't need to take care of that usecases.
>
> Pavel> Then they don't use Linux RPMs a
>
> It is chicken-and-egg problem. No OSGi support in RPMs => projects
> chose "redistribute all the required jar files" and ignore PRMs =>
> RPMs do not get better.

Not supporting OSGi does not necessarily mean that RPMs are not getting
better.  Users of jars from RPMs obviously do not care too much about
OSGi, otherwise this would have been already packaged..

> So the question is what is the purpose of pgjdbc.jar.rpm

In example:  I'm working on small Java project that needs to connect to
PostgreSQL.  So I wan't to install pgjdbc.jar -- but I do trust my Linux
distribution, not maven -- so all I need is to install that.  Hitting
'maven install' is not acceptable for me as a user at all, because I can't
be sure what are the consequences.

> if everybody redistributes the jar?

I don't understand this, can you elaborate please?

Pavel

Pavel> This is probably build product

It is a set of source files. You can't deny that.
You want the source, you get it.
The build script is missing, but *.spec is much better then as you
would be absolutely sure that nothing "unexpected" passes through.

Pavel>we can't bundle stuff like that.

There's no need to bundle that. It is a compile-time dependency to
build OSGi-enabled pgjdbc.

Vladimir>> if everybody redistributes the jar?
Pavel>I don't understand this, can you elaborate please?

From my experience, 99.9% of projects redistribute the required java libraries.
I've never seen cases when the jar files were pulled from PRMs coming
with the OS.

I wonder if there are live uses of "pgjdbc.rpm".

Pavel> I'm working on small Java project that needs to connect to
Pavel>PostgreSQL.

Virtually all development requires not just "jar files" that can talk
to the database, but development requires "javadoc&source" jars.
Javadoc&source jars are used to look into pgjdbc source
code&documentation and double-check if the method you are going to
apply indeed does what you think it should do.


Vladimir

On Monday 25 of January 2016 17:07:49 Vladimir Sitnikov wrote:
> Pavel> This is probably build product
>
> It is a set of source files. You can't deny that.
> You want the source, you get it.
> The build script is missing, but *.spec is much better then as you
> would be absolutely sure that nothing "unexpected" passes through.
>
> Pavel>we can't bundle stuff like that.
>
> There's no need to bundle that. It is a compile-time dependency to
> build OSGi-enabled pgjdbc.

Bundling is both about technical and non-technical issues.  So I would
consider this as bundling.

> Vladimir>> if everybody redistributes the jar?
> Pavel>I don't understand this, can you elaborate please?
>
> From my experience, 99.9% of projects redistribute the required java libraries.
> I've never seen cases when the jar files were pulled from PRMs coming
> with the OS.

Ah, thanks.  Yeah, I agree -- that will major set of Java projects.
There are pros/cons;  but this is again off-topic.

I just need to state that I discuss here to advocate different approach
(don't download the libraries over-and-over again).

> I wonder if there are live uses of "pgjdbc.rpm".

LibreOffice depend on pgjdbc, at least.  We provide jdbc in Red Hat
Enterprise Linux, because it is used by JBoss for example.  But it is not
just about this, those are just examples.

It is really that simple -- I need pgjdbc because I need to access
PostgreSQL server from my rather simple Java project.

So far I have to either use old jdbc driver, or use maven -- but if I do
require maven, I can't package my package into any distribution.  So I
rather don't use Java at all.  Yeah, chicken-egg problem.

> Pavel> I'm working on small Java project that needs to connect to
> Pavel>PostgreSQL.
>
> Virtually all development requires not just "jar files" that can talk
> to the database, but development requires "javadoc&source" jars.
> Javadoc&source jars are used to look into pgjdbc source
> code&documentation and double-check if the method you are going to
> apply indeed does what you think it should do.

Right, all distributions provide source and documentation.  Or if not, it
is a bug and nobody asked yet.  Usually (GNU GPL) you have to provide the
source, so this is strict rule of Red Hat at least.

Pavel

On Monday 25 of January 2016 08:46:56 Dave Cramer wrote:
> Well like it or not, spring is arguably the largest enterprise java
> dependency and it has hundreds if not thousands of dependencies which
> enterprise users happily download.

I can concur with you, Dave.  There are people who are OK with that.

> So I'm not sure how your argument holds water.

Sure.  You may choose to force users to use maven everywhere, via not
allowing us to build from source.  But I'm here please you not to do that.

> I would imagine from a redhat perspective redhat is the only trusted
> source.  However this is 2016 and the sheer volume of dependencies
> modern software requires makes this presumption untenable.

Substitute Red Hat with any Linux, FreeBSD, Solaris etc. distributions.
All of those are used and trusted.  At least nowadays -- making this
totally off-topic is not worth;  I'm just trying to build from source.

Believe it or not -- there are people who do not trust maven repositories
-- and I'm not sure whether PostgreSQL project should encourage people to
use maven repositories everywhere.  PostgreSQL should be re-distribuable
everywhere, if possible.

> This argument is not constructive but an attempt to show another point
> of view.

Ack.

> I have asked to join the osgi-dev list and will ask them how to deal
> with this issue

Right, but our mission is to distribute pgjdbc, not OSGi (which is
something osgi-dev will tell you probably).  If we could opt-out it, it
would be fine.

Pavel

On Monday 25 of January 2016 09:11:51 Dave Cramer wrote:
> >
> >
> > From my experience, 99.9% of projects redistribute the required java
> > libraries.
> > I've never seen cases when the jar files were pulled from PRMs coming
> > with the OS.
> >
> > I wonder if there are live uses of "pgjdbc.rpm".
> >
> >
>
> This is a good question and one for which you should have metrics as the
> latest jar has not been included in the redhat distro for quite some while.

No, we provide postgresql-jdbc.  What makes you think this?  That's is one
of the reasons why we are here in this discussion.

We always try to be as much up2date with upstream, but we are now behind,
unfortunately.

> How many tickets do you have asking for the jar ?

None, just for the update:

  1196445  postgresql-jdbc-9.4-1207 is available
  1217395  update maven notation
  1222596  postgresql-jdbc should depend on java-headless instead of java
  1255374  Incorrect mvn() Provides and pom.xml data

> Are there any other projects which require the jar ?

Answered in separate branch of this thread.

Pavel

On Monday 25 of January 2016 15:33:18 Pavel Raiskup wrote:
> On Monday 25 of January 2016 08:46:56 Dave Cramer wrote:
> > Well like it or not, spring is arguably the largest enterprise java
> > dependency and it has hundreds if not thousands of dependencies which
> > enterprise users happily download.
>
> I can concur with you, Dave.  There are people who are OK with that.
>
> > So I'm not sure how your argument holds water.
>
> Sure.  You may choose to force users to use maven everywhere, via not
> allowing us to build from source.  But I'm here please you not to do that.
>
> > I would imagine from a redhat perspective redhat is the only trusted
> > source.  However this is 2016 and the sheer volume of dependencies
> > modern software requires makes this presumption untenable.
>
> Substitute Red Hat with any Linux, FreeBSD, Solaris etc. distributions.
> All of those are used and trusted.  At least nowadays -- making this
> totally off-topic is not worth;  I'm just trying to build from source.
>
> Believe it or not -- there are people who do not trust maven repositories
> -- and I'm not sure whether PostgreSQL project should encourage people to
> use maven repositories everywhere.  PostgreSQL should be re-distribuable
> everywhere, if possible.
>
> > This argument is not constructive but an attempt to show another point
> > of view.
>
> Ack.
>
> > I have asked to join the osgi-dev list and will ask them how to deal
> > with this issue
>
> Right, but our mission is to distribute pgjdbc, not OSGi (which is
> something osgi-dev will tell you probably).  If we could opt-out it, it
> would be fine.

Just a quick observation while trying to convince you that GNU/Linux
distributions do care about pgjdbc package-ability:

Gentoo build scripts:
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/jdbc-postgresql/jdbc-postgresql-9.4_p1206.ebuild
Which is something I'm trying to avoid, but yes -- they were able to
rebase to 1206 thanks to those hacks.

Arch linux has pgjdbc in AUR repository.  It means that there is no
support -- the reason is because they do not build from source;  they
download the binary from upstream repository.
https://aur.archlinux.org/packages/postgresql-jdbc/

Debian has already been discussed.  Way too old packages.

OpenSUSE (9.4.1201):
https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/postgresql-jdbc/postgresql-jdbc.spec?expand=1

Pavel

     Hi everybody. Top-posting here to avoid getting into finer detail,
providing more general opinion here.

     To me the value of having pgjdbc packaged for Fedora/Red Hat, and
having it up to date, is undeniable. So let's find the ways to get it
done :)

     Now I don't see productive analyzing one by one whether the
dependencies should be individually packaged or not. This is a very
common problem (or feature, as you may see it) of Java development, and
resolving it on a use-by-use case won't help. This kind of requires a
more general solution.

     It is a good question why there are not packages like OSGI in rpm
already packaged. I understand the database team does not want to
maintain such package. What I see here is that there's a significant
"impedance mismatch" between distro packaging and Java. I strongly
believe this is the main reason there are few Java packages in the
distros, not that few users need it. Most Java users that use most Java
programs, in my experience, either download compiled, "fat" JARs (all
dependencies included) or use Maven. Few use pre-packaged distro
software (usually because it's unavailable).

     And again, the reason for this is that Java development tends to
include one or several dependencies, and the ecosystem of dependencies
is huge (in my POV greater than any other language ecosystem, and by
far). So we have to consider one of the following two alternatives:

- Take every dependency on any Java software to package (pgjdbc in this
case) and also package it as a separate package. This IMHO might get
crazy with other projects with more dependencies, since that may split
the process into even dozens of packages.
- Take the source of those dependencies, install it locally prior to
package building, and provide all as a single unit.

     The first method might be a burden on the packagers and might not
be convenient in many senses. The second one is thus probably the best
one. It might sound terrible if several packages will end up packaging
the same code and not reusing it; but in Java (different apps) this is
hardly a problem (as it is in C with shared libraries).

     So I'd suggest to focus on this second approach. Whether we like
OSGI or not, it is a feature of the current driver, and should not be
removed lightly. It diminishes its value. However, I understand that it
may not be packaged individually (more packages to maintain). So mi big
question is:

Can OSGI dependency be pulled -as source, of course- into build
preparation phase, compile locally (mvn install or any alternative mean)
and ship it integrated with the pgjdbc package?

     Cheers,

     Álvaro



On 25/01/16 16:33, Pavel Raiskup wrote:
> On Monday 25 of January 2016 15:33:18 Pavel Raiskup wrote:
>> On Monday 25 of January 2016 08:46:56 Dave Cramer wrote:
>>> Well like it or not, spring is arguably the largest enterprise java
>>> dependency and it has hundreds if not thousands of dependencies which
>>> enterprise users happily download.
>> I can concur with you, Dave.  There are people who are OK with that.
>>
>>> So I'm not sure how your argument holds water.
>> Sure.  You may choose to force users to use maven everywhere, via not
>> allowing us to build from source.  But I'm here please you not to do that.
>>
>>> I would imagine from a redhat perspective redhat is the only trusted
>>> source.  However this is 2016 and the sheer volume of dependencies
>>> modern software requires makes this presumption untenable.
>> Substitute Red Hat with any Linux, FreeBSD, Solaris etc. distributions.
>> All of those are used and trusted.  At least nowadays -- making this
>> totally off-topic is not worth;  I'm just trying to build from source.
>>
>> Believe it or not -- there are people who do not trust maven repositories
>> -- and I'm not sure whether PostgreSQL project should encourage people to
>> use maven repositories everywhere.  PostgreSQL should be re-distribuable
>> everywhere, if possible.
>>
>>> This argument is not constructive but an attempt to show another point
>>> of view.
>> Ack.
>>
>>> I have asked to join the osgi-dev list and will ask them how to deal
>>> with this issue
>> Right, but our mission is to distribute pgjdbc, not OSGi (which is
>> something osgi-dev will tell you probably).  If we could opt-out it, it
>> would be fine.
> Just a quick observation while trying to convince you that GNU/Linux
> distributions do care about pgjdbc package-ability:
>
> Gentoo build scripts:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/jdbc-postgresql/jdbc-postgresql-9.4_p1206.ebuild
> Which is something I'm trying to avoid, but yes -- they were able to
> rebase to 1206 thanks to those hacks.
>
> Arch linux has pgjdbc in AUR repository.  It means that there is no
> support -- the reason is because they do not build from source;  they
> download the binary from upstream repository.
> https://aur.archlinux.org/packages/postgresql-jdbc/
>
> Debian has already been discussed.  Way too old packages.
>
> OpenSUSE (9.4.1201):
> https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/postgresql-jdbc/postgresql-jdbc.spec?expand=1
>
> Pavel
>

Best regards, Vitalii Tymchyshyn

On Tuesday 26 of January 2016 03:34:00 Vitalii Tymchyshyn wrote:
> Well, first of all you dont need to package osgi classes. Those are the
> apis and as soon as you run in the osgi container, they are provided by
> container. But you need those to build the driver. And af far as I
> understand, there are certain licensing problems to do this, ain't they? I
> dont think it's pure packaging problem, e.g. see
> https://lists.fedoraproject.org/pipermail/legal/2012-July/001930.html.

Thanks, I was not aware of that.  This makes clear why people probably
want OSGi enterprise, but it can not live in open source distribution.

I'm not sure, is it safe to depend on it in upstream?

Pavel

> Thats why alternative sources of API were proposed.
>
> Best regards, Vitalii Tymchyshyn
>
> Пн, 25 січ. 2016 20:58 Álvaro Hernández Tortosa <aht@8kdata.com> пише:
>
> >
> >      Hi everybody. Top-posting here to avoid getting into finer detail,
> > providing more general opinion here.
> >
> >      To me the value of having pgjdbc packaged for Fedora/Red Hat, and
> > having it up to date, is undeniable. So let's find the ways to get it
> > done :)
> >
> >      Now I don't see productive analyzing one by one whether the
> > dependencies should be individually packaged or not. This is a very
> > common problem (or feature, as you may see it) of Java development, and
> > resolving it on a use-by-use case won't help. This kind of requires a
> > more general solution.
> >
> >      It is a good question why there are not packages like OSGI in rpm
> > already packaged. I understand the database team does not want to
> > maintain such package. What I see here is that there's a significant
> > "impedance mismatch" between distro packaging and Java. I strongly
> > believe this is the main reason there are few Java packages in the
> > distros, not that few users need it. Most Java users that use most Java
> > programs, in my experience, either download compiled, "fat" JARs (all
> > dependencies included) or use Maven. Few use pre-packaged distro
> > software (usually because it's unavailable).
> >
> >      And again, the reason for this is that Java development tends to
> > include one or several dependencies, and the ecosystem of dependencies
> > is huge (in my POV greater than any other language ecosystem, and by
> > far). So we have to consider one of the following two alternatives:
> >
> > - Take every dependency on any Java software to package (pgjdbc in this
> > case) and also package it as a separate package. This IMHO might get
> > crazy with other projects with more dependencies, since that may split
> > the process into even dozens of packages.
> > - Take the source of those dependencies, install it locally prior to
> > package building, and provide all as a single unit.
> >
> >      The first method might be a burden on the packagers and might not
> > be convenient in many senses. The second one is thus probably the best
> > one. It might sound terrible if several packages will end up packaging
> > the same code and not reusing it; but in Java (different apps) this is
> > hardly a problem (as it is in C with shared libraries).
> >
> >      So I'd suggest to focus on this second approach. Whether we like
> > OSGI or not, it is a feature of the current driver, and should not be
> > removed lightly. It diminishes its value. However, I understand that it
> > may not be packaged individually (more packages to maintain). So mi big
> > question is:
> >
> > Can OSGI dependency be pulled -as source, of course- into build
> > preparation phase, compile locally (mvn install or any alternative mean)
> > and ship it integrated with the pgjdbc package?
> >
> >      Cheers,
> >
> >      Álvaro
> >
> >
> >
> > On 25/01/16 16:33, Pavel Raiskup wrote:
> > > On Monday 25 of January 2016 15:33:18 Pavel Raiskup wrote:
> > >> On Monday 25 of January 2016 08:46:56 Dave Cramer wrote:
> > >>> Well like it or not, spring is arguably the largest enterprise java
> > >>> dependency and it has hundreds if not thousands of dependencies which
> > >>> enterprise users happily download.
> > >> I can concur with you, Dave.  There are people who are OK with that.
> > >>
> > >>> So I'm not sure how your argument holds water.
> > >> Sure.  You may choose to force users to use maven everywhere, via not
> > >> allowing us to build from source.  But I'm here please you not to do
> > that.
> > >>
> > >>> I would imagine from a redhat perspective redhat is the only trusted
> > >>> source.  However this is 2016 and the sheer volume of dependencies
> > >>> modern software requires makes this presumption untenable.
> > >> Substitute Red Hat with any Linux, FreeBSD, Solaris etc. distributions.
> > >> All of those are used and trusted.  At least nowadays -- making this
> > >> totally off-topic is not worth;  I'm just trying to build from source.
> > >>
> > >> Believe it or not -- there are people who do not trust maven
> > repositories
> > >> -- and I'm not sure whether PostgreSQL project should encourage people
> > to
> > >> use maven repositories everywhere.  PostgreSQL should be re-distribuable
> > >> everywhere, if possible.
> > >>
> > >>> This argument is not constructive but an attempt to show another point
> > >>> of view.
> > >> Ack.
> > >>
> > >>> I have asked to join the osgi-dev list and will ask them how to deal
> > >>> with this issue
> > >> Right, but our mission is to distribute pgjdbc, not OSGi (which is
> > >> something osgi-dev will tell you probably).  If we could opt-out it, it
> > >> would be fine.
> > > Just a quick observation while trying to convince you that GNU/Linux
> > > distributions do care about pgjdbc package-ability:
> > >
> > > Gentoo build scripts:
> > >
> > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/jdbc-postgresql/jdbc-postgresql-9.4_p1206.ebuild
> > > Which is something I'm trying to avoid, but yes -- they were able to
> > > rebase to 1206 thanks to those hacks.
> > >
> > > Arch linux has pgjdbc in AUR repository.  It means that there is no
> > > support -- the reason is because they do not build from source;  they
> > > download the binary from upstream repository.
> > > https://aur.archlinux.org/packages/postgresql-jdbc/
> > >
> > > Debian has already been discussed.  Way too old packages.
> > >
> > > OpenSUSE (9.4.1201):
> > >
> > https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/postgresql-jdbc/postgresql-jdbc.spec?expand=1
> > >
> > > Pavel
> > >
> >
> >

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

On Tuesday 26 of January 2016 07:18:27 Dave Cramer wrote:
> On 26 January 2016 at 02:13, Pavel Raiskup <praiskup@redhat.com> wrote:
>
> > On Tuesday 26 of January 2016 03:34:00 Vitalii Tymchyshyn wrote:
> > > Well, first of all you dont need to package osgi classes. Those are the
> > > apis and as soon as you run in the osgi container, they are provided by
> > > container. But you need those to build the driver. And af far as I
> > > understand, there are certain licensing problems to do this, ain't they?
> > I
> > > dont think it's pure packaging problem, e.g. see
> > > https://lists.fedoraproject.org/pipermail/legal/2012-July/001930.html.
> >
> > Thanks, I was not aware of that.  This makes clear why people probably
> > want OSGi enterprise, but it can not live in open source distribution.
> >
> > I'm not sure, is it safe to depend on it in upstream?
> >
>
> The only reason it is bad is that it forbids modification which if you
> think about it's purpose makes sense.

This never makes sense in open source world - disagreement here :(.  Any
open project could say it makes sense to "protect you" from bad changes.

It is basically ugly closed-source -- because "good" open source licenses
try to protect you users from vendor lock-in -- and osgi.enterprise
basically is vendor lock-in:

  consider that you are not able to build osgi.enterprise because java
  changes a bit (system dep changes a bit), etc.  -- then you are locked
  in state of waiting for new upstream release or reimplement

This is not acceptable, unfortunately.

> It is attempting to provide an agreed upon way to include services into
> an enterprise. If everyone modified it how would it work

The license is not good tool to guarantee this.

> I don't see the difference between this and JDBC for instance

IANAL, but to me this makes it incompatible with other free licenses that
*requires* you to keeping the source modifiable?

Pavel

On Tuesday 26 of January 2016 08:49:53 Dave Cramer wrote:
> My point is that you would not change the JDBC API, even if it was
> freebsd licensed as your code would immediately become useless

Agreed.

> Same with OSGI, it is meant as a common interface for everyone to be able
> to discover services. Breaking the contract by changing the code makes the
> code useless IMO

Agreed.  (By that I mean that it makes not sense to change the API, and it
also makes no sense forcing you to use the code as read-only.)

> So we are in a bit of a quandry here. I do not think it is the JDBC's
> mandate to be acceptable to distros.

No, but you say you are free software (PostgreSQL license under
postgresql.org domain):


  | Copyright (c) 1997-2011, PostgreSQL Global Development Group All rights
  | reserved.
  |
  | Redistribution and use in source and binary forms, with or without
  | modification, are permitted provided that the following conditions are
    ^^^^^^^^^^^^
  | [skip]

Again, vendor lock-in is really wrong;  and *ANY* redistribution of jdbc
now requires software (for build) that is subject of vendor lock-in
issues.

> It is my understanding that much of the packaging work involves changing
> projects to that they are compatible with the distro.

No :(.  Not "much of the" packaging work -- usually there are no problems
with packaging (at least as far as I'm concerned in Fedora).

But yes, we do submit patches (or discuss before we submit patches) which
is usually good thing for upstream, too.

> Even that is somewhat of a problem since a user would expect all of the
> functionality that the JDBC project provides.

I am claiming all the time that distro users do not expect that
functionality in question -- and if yes, they always can use maven if they
are OK with that.

That's why I think the "core" functionality should stay FOSS, as it used
to be for very, very long time.  OSGi support would be fine to have
optionally as separate jar wrapper (or something like that) -- I do agree
that is useful feature for osgi.enterprise users.

> If the distro decides to cut pieces out of it the user is going to find
> that their code works on X and not on Y environment.

This is different question, but yes -- the software is provided supported
for concrete environment usually.  But that is normal -- on proprietary OS
you also expect issues if you migrate from version N to version N+1.

Pavel

On Tuesday 26 of January 2016 14:01:12 Vitalii Tymchyshyn wrote:
> > 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.

Probably my mistake sorry, I thought you think about downloading jar file
provide by RPM binary package (which is kind of cpio archive) -- to
replace the jar provided e.g. by maven.  Such scenario does not exist.

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

If the project does not depend on the missing feature, it _is going to
work_ transparently.  If the project does depend on something which is
not in Fedora, it is going to fail.  There are ways how to get out from
this issue
   - you need to package the dependencies;  but still it is much easier to
     not forcing people to do that

> BTW: Why do you think it's not supported? It's supported, but support is
> outdated.

For example -- we do support some Felix parts ATM in Fedora.  Because that
is not up2date, it sounds nobody cares too much (Fedora is otherwise as
far as possible up2date distro).  Do other distributions provide those
packages?  Because I do not want to fix Fedora only.

Making "just" connector between Java and PG hard-depending on something is
not worth.

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

Right!  Or better to have the split done so that 'pgjdbc' and
'pgjdbc-osgi'.  E.g. by inheritance you can "enlarge" the pgjdbc
functionality and then depend on 'pgjdbc'.  That would be awesome.  I
would be able to help with packaging of 'pgjdbc-osgi' (not for Fedora
repositories of course).

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

Agreed.

Thanks,
Pavel

On Tuesday 26 of January 2016 16:19:25 Pavel Raiskup wrote:
> > 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).
>
> Right!  Or better to have the split done so that 'pgjdbc' and
> 'pgjdbc-osgi'.  E.g. by inheritance you can "enlarge" the pgjdbc
> functionality and then depend on 'pgjdbc'.  That would be awesome.  I
> would be able to help with packaging of 'pgjdbc-osgi' (not for Fedora
> repositories of course).

Gently pinging here :).  Could we think about something like this?  Has
the discussion with osgi.enterprise guys moved somewhere?

Thanks, Pavel