Re: Complicated re-distribution of pgjdbc the "open source way"

As for me, the problem is not about JDBC driver, the problem is with FOSS
world not able to deal with OSGI recently. It neither starts nor stops with
PgJDBC. And for me it's not a reason to make some useful feature optional
complicating things for a user (instead of per-JDK jar you are starting to
produce at least twice as many jars to deal with).
And it's not a technical limitation - current jars work perfectly in
non-OSGI environment and runtime dependency resolution is the way java
world tries to live.
Guys, you really need to decide with OSG in general. How are you going to
deal with modern versions of containers like JBoss that has OSGi as a core
feature? That is the problem.
You used to use API files from Felix, but they dont produce fresh versions
anymore, possiby after switching to the official API jars. Contact them to
check it.

Best regards, Vitalii Tymchyshyn

Вт, 8 бер. 2016 07:08 користувач Pavel Raiskup <praiskup(at)redhat(dot)com> пише:

> On Tuesday 08 of March 2016 14:37:56 Vladimir Sitnikov wrote:
> > Pavel>Not modifiable code is vendor-lock-in
> >
> > org.osgi.enterprise jar is Apache 2.0-licensed.
> > Apache 2.0 allows modification of a source code. Surprise.
>
> It is actually not correct, as far as I am aware. The links you provided
> so far are results of official build, which puts the sources there by
> default. Can we convince upstream to release official tarballs without
> the "signature needed" request that disallows you to modify?
>
> > Pavel>I our case, it is IMO no need to test the potentially opt-outed
> > Pavel>feature,
> >
> > You claim to "invent common build denominator feature", then you claim
> > "there's no need to test it".
> > Are you kidding?
>
> Yes, here is your excuse :) I talked about, or?
>
> You test your full-feature-set you support ATM. That is fine, I do not
> plan to stop testing something.
>
> Some people (not you but me!) do want to disable something for themselves,
> what exactly do you want to test on it?
> But we can probably simulate the situation for you -- we can always do two
> builds in upstream CI -- with/without the feature, even though you support
> only the first scenario. Do I understand it right this is wanted?
>
> > As per Dave's words: "can you explain why packaging can't be tested"?
> > "no need" != "can't" as far as I can understand.
> > I think package testing should be rather simple.
>
> It is tested. I don't think you want it upstream as you don't support
> packages we re-distribute.
>
> > Pavel> It is not needed to check in upstream
> > Pavel>that the opt-out feature works
> >
> > You seem to ignore the main aim of testing. The tests are there to
> > catch unintentional changes.
>
> No. I appreciate testing, be fair please.
>
> You know that there are tests _already_; that would catch the issues we
> could potentially add into existing level of your support ... so we can
> fix the patches we propose to not do that.
>
> I just say -- don't test that the '--opt-out-waffle' and '--opt-no-osgi',
> whatever format it will have. Then you know that "nobody" except for
> packagers use those -- and the guys know how to fix this if something
> wrong happens...
>
> > If no tests added, any innocent refactoring might break your packaging
> > script.
>
> And, again -- don't be afraid here, that is why we are here. You can not
> provide packaging scripts for the whole world, it is not upstream
> responsibility and no upstream does this.
>
> Pavel
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>