On 02/02/15 17:50, Stian Soiland-Reyes wrote:
OK, agree that it should be easy out of the box to compile.
With remove you mean to move out of source code or just not include it
in the release?
Out of the source tree. That's clear cut.
Just disabling it in <modules> (or require the -Papache-release flag)
would work for me.
The test source is IP and license clean - so there's no issue with it
hanging around.
But there is a non-"provided" dependency on LGPL.
The PAX solution should work, but needs some more developer time I am
not sure exactly when I can promise to do - but possibly this week
depending on how late the kids get to bed ... :)
Either 2.13.0 isn't going to be immediate or we go for a several
releases. There are Fuseki2 reports to be dealt with, and the not
respecting config issue looks like it would be better to do before, if
that's already with people. This OSGi module is proving time consuming.
(Stian - there is no such as a "blocker" unless we all agree it - anyone
can release at anytime. It's just our documented prcoess is committer
centric.)
Andy
On 2 February 2015 at 15:32, Andy Seaborne <[email protected]> wrote:
On 02/02/15 13:30, Stian Soiland-Reyes wrote:
So the jena-osgi-test is not needed for *building* any artifacts
(except itself, which doesn't depend on LGPL but probably need not be
pushed to Maven central anyway). jena-osgi-test is not required for
anything else. The test is only run during the integration-test phase
(which happens during mvn install).
Not convinced. It's not about us building artifact, it's about a downstream
user.
* Download source-release and unzip.
* mvn clean install
to get a local build.
That uses the test jena-osgi-test (if it were not commented out.)
Whether it's maven/test or maven/compile is not a clear distinction. The
build process we ship runs tests.
- - - - - - - -
This is getting complicated and a delay on 2.13.0.
One route forward is to remove jena-osgi-test for 2.13.0, that is, "we" test
separately, and wait for an AL based one in a future release.
Andy
It does however seems to still be run if you do mvn install
-DskipTests -Papache-release - perhaps the profile in
apache-jena-osgi/pom.xml could be improved to also check for that
property.
If only enabling it through -Papache-release is not enough, perhaps we
could for now just leave jena-osgi-test there, uncommented from the
parent - and then someone (I guess myself) would have to remember to
run it for every release candidate?
On 2 February 2015 at 13:11, Andy Seaborne <[email protected]> wrote:
On 02/02/15 11:33, Stian Soiland-Reyes wrote:
2/ There is a LGPL dependency (scope test) which needs investigation.
(I would have appreciated that having been pointed out first)
Sorry, I didn't mention this outside the pom.xml as it was a
build/test dependency, which I thought would be OK - given:
https://www.apache.org/legal/resolved.html#prohibited
The eosgi-maven-plugin Maven plugin is also LGPL.
That's not what resolved.html#prohibited is referring to. That is
general
principles, not java specific.
An Apache release must be reproducible; it's not just code.
The source-resource that is the formal release must be buildable by a
down-stream user. Jena ships our repo (the Apache parent does the work).
The down-stream user must be able to build the same artifacts; they may
wish
to check against any binaries in maven, or to modify them. Just maven
-sources is not enough. maven central is not n Apache hardware.
As far as I know, we can not ship source-release that pulls in LGPL, even
to
test, without the user making an explicit act to knowingly do that and
work
without it.
How do other projects do testing?
Andy
