Re: Merge pgjdbc-parent-poms project into pgjdbc please - Mailing list pgsql-jdbc
From | Pavel Raiskup |
---|---|
Subject | Re: Merge pgjdbc-parent-poms project into pgjdbc please |
Date | |
Msg-id | 2111371.VHhDSrkGXe@nb.usersys.redhat.com Whole thread Raw |
In response to | Re: Merge pgjdbc-parent-poms project into pgjdbc please (Vitalii Tymchyshyn <vit@tym.im>) |
Responses |
Re: Merge pgjdbc-parent-poms project into pgjdbc please
|
List | pgsql-jdbc |
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
pgsql-jdbc by date: