I am in the process of creating package torodb (https://github.com/torodb/torodb) for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1302156). postgresql-jdbc is a torodb's dependency and, if possible, our goal is to include it in Fedora 22 and above. Actually we are trying to add the postgresql jdbc driver latest version as a bundle in our package but, as Pavel Raiskup told us, the right way is to have it stand-alone and depend on it. Since we have same goal to build the postgresql jdbc driver I decided to kick in and share my progresses with the community.
For now I just removed waffle dependency patching code (attached) and removing a couple classes from build:
Actually I am looking into the org.osgi.enterprise artifact dependency that is missing, as you mentioned, due to incompatible license with Fedora. After investigating a bit I found out that org.osgi.enterprise library is shipped with an Apache License (Version 2.0, January 2004) so it is not clear to me if there are license issues or not. In any case postgresql-jdbc package use a single interface (org.osgi.service.jdbc.DataSourceFactory) from artifact org.osgi.enterprise. It would be really trivial to generate a clean room implementation of the interface and put it in a separate package or just use for build without installing.
Current version in Fedora is behind latest version of postgresql-jdbc (1200 vs 1207).
We are trying to package latest version into Fedora, but there are dependencies, which are not useless in Fedora (waffle-jna)
Which *are* useless in Fedora. I know that was just an editing mistake. It's a library used in PgJDBC for windows SSPI support.
I don't really see the problem here. If your packaging policy prevents you from incorporating it, patch it out. It's use is simple, self-contained and already optional.
and ones which we are not 100% open source (osgi-enterprise). We talked with upstream quite intensively but not been able to find any solution which would meet our requirements.
... which you should probably outline here, because otherwise nobody will understand the problem.
We think that it's not a good, when open-source project depending on packages, which licence is not 100% clear.
Well, frankly, that's Java. So long as they're soft-dependencies I really don't care.
I've already explained the JDBC position here.
There is an impedance mismatch between the java ecosystem and distros.
We have moved to maven as have most other java projects.
As Craig said, if you want to build it, patch it out, and create a ant/Makefile to make the jar.