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

On Tuesday 08 of March 2016 12:27:32 Vitalii Tymchyshyn wrote:
> As for me, the problem is not about JDBC driver, the problem is with FOSS
> world not able to deal with OSGI recently.

Then the actual status works for you.  It is completely fine, but there
are other who do care and who prefer different ideas, and there should be
a way to lock ourselves somewhere.

> It neither starts nor stops with PgJDBC.

Truth.

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

I need to react because of this ^.  PostgreSQL server has a lot of
features available during build, try './configure --help'.  You can choose
what features are important for you, and what not.

The opt-out (unused by upstream probably) in pgjdbc I would like to see is
far from being that sophisticated.  What is the problem with this?

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

Note the whole Java world probably.  I, for example, can consider myself
as somebody somebody who needs to write some gui app in Java, than
distribute that as native package for distributions.  More!  I want the
distribution guys do it for myself.  But I can't use jdbc, because it is
not provided natively -- and I can't thus use Java, because I can't
connect to PostgreSQL.

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

JBoss is not Fedora.  We can't pull everything into Fedora just because we
want to connect 'A with B' where both 'A' and 'B' are already there and we
are fine with that.  To connect 'A' with 'B' is needed 'C (osgi support)'
and 'D (waffle)', where we are not able to provide 'D' and 'C' is not
needed atm (somebody tried to deal with that in Y2012, and we did not move
forward yet in 2016).  We need solution now, and we can enable things
later.

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

I'll discuss this locally and report back, but it is not related ATM.
Some features are naturally expected to be optional, and that is why I'm
here.

Fedora is where it is in this case and I'm unfortunately unable to change
that (I'm not going to provide and support waffle and osgi just to provide
jdbc).

Pavel

> Best regards, Vitalii Tymchyshyn
>
> Вт, 8 бер. 2016 07:08 користувач Pavel Raiskup <praiskup@redhat.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@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-jdbc
> >