Re: Complicated re-distribution of pgjdbc the "open source way" - Mailing list pgsql-jdbc
| From | Vitalii Tymchyshyn |
|---|---|
| Subject | Re: Complicated re-distribution of pgjdbc the "open source way" |
| Date | |
| Msg-id | CABWW-d0tkP2UHckqsdsLsSGatEj8_ebX=nM3shQxdXP0oq=c=w@mail.gmail.com Whole thread Raw |
| In response to | Re: Complicated re-distribution of pgjdbc the "open source way" (Pavel Raiskup <praiskup@redhat.com>) |
| Responses |
Re: Complicated re-distribution of pgjdbc the "open source way"
(Pavel Raiskup <praiskup@redhat.com>)
|
| List | pgsql-jdbc |
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@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
pgsql-jdbc by date: