You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2015/01/30 16:02:00 UTC
Jena OSGi pull request
https://github.com/apache/jena/pull/10
Conversations around this seem to have settled down around the latest
state of pull request 10 (to me as a non-OSGi person).
I propose to pull and merge this.
This message is lazy consensus (24hr minimum deadline) on pulling that
so that there will be a new module "jena-osgi".
Given it has to get into the build routine and settle down, I'd like to
not put decisions on the exact name onto the critical path for pulling
the request.
Naming:
1/ Should it be "apache-jena-osgi" as a delivery module?
2/ Or have a stable point apache-jena-osgi<type>pom</type> to point to
"jena-osgi"
3/ or leave it as jena-osgi and think about the name after 2.13.0 as
feedback comes in (i.e. a sort of "beta")
If there is an emerging consensus now on a different name, I'll do that
else put it in as jena-osgi and rename after due consideration.
We can then close:
https://issues.apache.org/jira/browse/JENA-190
Andy
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 2 February 2015 at 17:03, Andy Seaborne <an...@apache.org> wrote:
> I think it's a different audience.
>
> apache-jena-dist is for standalong use + source + javadoc.
Right, that is what I would prefer as well.
So if/when we go for a Jena-OSGi download, it would be a separate one.
So you are happy with its binary going into Maven Central only for now then?
> Please could you separate the different aspects from your new pull request?
> Mixing NOTICE with comment fixes makes merging harder.
Done.
Pull request 21 is now only the things in this email thread on ms and
commented out bit in pom.xml
See other requests at https://github.com/apache/jena/pulls
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
On 02/02/15 11:53, Stian Soiland-Reyes wrote:
> Did you mean to just include the jena-osgi.jar in the apache-jena/
> dist? It would add only 7 MB.
I think it's a different audience.
apache-jena-dist is for standalong use + source + javadoc.
I'd rather start cautious and add later, rather than add now and feel
obliged to continue that.
> If on the otherside we do a separate download of jena-osgi, we
> probably want a separate 'apache-' like dist ZIP/tar.gz instead of the
> direct JAR file - not sure how well the mirrors (and anti virus
> software) would like a direct JAR download.
>
>
> This would need to include the bundle JAR inside with a README and
> extract the NOTICE.
Please could you separate the different aspects from your new pull
request? Mixing NOTICE with comment fixes makes merging harder.
(And why aren't pull requests emailing dev@jena?)
>
>
> Also - should a OSGi download ZIP also contain the other bundles it
> depend on? (Similar to lib/ in the Jena distribution)? I am not sure
> if this would be convenient or not for Non-Maven OSGi users.
>
> It's not that big:
>
> stain@biggie-utopic:~/src/jena/apache-jena-osgi/jena-osgi-test/target/eosgi-dist$
> du -hs felix/lib
> 11M felix/lib
> stain@biggie-utopic:~/src/jena/apache-jena-osgi/jena-osgi-test/target/eosgi-dist$
> ls felix/lib/
> commons-csv-1.0.jar jcl-over-slf4j-1.7.6.jar
> org.everit.osgi.dev.testrunner.junit4-3.0.4.jar
> commons-lang3-3.3.2.jar jena-osgi-2.13.0-SNAPSHOT.jar
> org.ops4j.pax.tipi.hamcrest.core-1.3.0.1.jar
> httpclient-osgi-4.2.6.jar jena-osgi-test-2.13.0-SNAPSHOT.jar
> org.ops4j.pax.tipi.junit-4.11.0.1.jar
> httpcore-osgi-4.2.5.jar jsonld-java-0.5.1.jar
> slf4j-api-1.7.6.jar
> jackson-annotations-2.3.0.jar libthrift-0.9.2.jar
> slf4j-log4j12-1.7.6.jar
> jackson-core-2.3.3.jar log4j-1.2.17.jar
> jackson-databind-2.3.3.jar org.everit.osgi.dev.testrunner-4.0.3.jar
>
> (The *-test and everit/ops4j bits wouldn't be in such a dist)
>
>
> This reminds me - shouldn't jena-osgi include the additional notices
> as in apache-jena/NOTICE?
>
> In the jena-osgi-tidy pull-request I copy-pasted the relevant bits
> (only Jena and Xerces bits) now to jena-osgi/META-INF/NOTICE
>
> .. ideally this should be generated by Maven. Are there any others I forgot?
>
>
> On 30 January 2015 at 15:02, Andy Seaborne <an...@apache.org> wrote:
>> https://github.com/apache/jena/pull/10
>>
>> Conversations around this seem to have settled down around the latest state
>> of pull request 10 (to me as a non-OSGi person).
>>
>> I propose to pull and merge this.
>>
>> This message is lazy consensus (24hr minimum deadline) on pulling that so
>> that there will be a new module "jena-osgi".
>>
>> Given it has to get into the build routine and settle down, I'd like to not
>> put decisions on the exact name onto the critical path for pulling the
>> request.
>>
>> Naming:
>>
>> 1/ Should it be "apache-jena-osgi" as a delivery module?
>>
>> 2/ Or have a stable point apache-jena-osgi<type>pom</type> to point to
>> "jena-osgi"
>>
>> 3/ or leave it as jena-osgi and think about the name after 2.13.0 as
>> feedback comes in (i.e. a sort of "beta")
>>
>> If there is an emerging consensus now on a different name, I'll do that else
>> put it in as jena-osgi and rename after due consideration.
>>
>> We can then close:
>>
>> https://issues.apache.org/jira/browse/JENA-190
>>
>> Andy
>
>
>
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
Did you mean to just include the jena-osgi.jar in the apache-jena/
dist? It would add only 7 MB.
If on the otherside we do a separate download of jena-osgi, we
probably want a separate 'apache-' like dist ZIP/tar.gz instead of the
direct JAR file - not sure how well the mirrors (and anti virus
software) would like a direct JAR download.
This would need to include the bundle JAR inside with a README and
extract the NOTICE.
Also - should a OSGi download ZIP also contain the other bundles it
depend on? (Similar to lib/ in the Jena distribution)? I am not sure
if this would be convenient or not for Non-Maven OSGi users.
It's not that big:
stain@biggie-utopic:~/src/jena/apache-jena-osgi/jena-osgi-test/target/eosgi-dist$
du -hs felix/lib
11M felix/lib
stain@biggie-utopic:~/src/jena/apache-jena-osgi/jena-osgi-test/target/eosgi-dist$
ls felix/lib/
commons-csv-1.0.jar jcl-over-slf4j-1.7.6.jar
org.everit.osgi.dev.testrunner.junit4-3.0.4.jar
commons-lang3-3.3.2.jar jena-osgi-2.13.0-SNAPSHOT.jar
org.ops4j.pax.tipi.hamcrest.core-1.3.0.1.jar
httpclient-osgi-4.2.6.jar jena-osgi-test-2.13.0-SNAPSHOT.jar
org.ops4j.pax.tipi.junit-4.11.0.1.jar
httpcore-osgi-4.2.5.jar jsonld-java-0.5.1.jar
slf4j-api-1.7.6.jar
jackson-annotations-2.3.0.jar libthrift-0.9.2.jar
slf4j-log4j12-1.7.6.jar
jackson-core-2.3.3.jar log4j-1.2.17.jar
jackson-databind-2.3.3.jar org.everit.osgi.dev.testrunner-4.0.3.jar
(The *-test and everit/ops4j bits wouldn't be in such a dist)
This reminds me - shouldn't jena-osgi include the additional notices
as in apache-jena/NOTICE?
In the jena-osgi-tidy pull-request I copy-pasted the relevant bits
(only Jena and Xerces bits) now to jena-osgi/META-INF/NOTICE
.. ideally this should be generated by Maven. Are there any others I forgot?
On 30 January 2015 at 15:02, Andy Seaborne <an...@apache.org> wrote:
> https://github.com/apache/jena/pull/10
>
> Conversations around this seem to have settled down around the latest state
> of pull request 10 (to me as a non-OSGi person).
>
> I propose to pull and merge this.
>
> This message is lazy consensus (24hr minimum deadline) on pulling that so
> that there will be a new module "jena-osgi".
>
> Given it has to get into the build routine and settle down, I'd like to not
> put decisions on the exact name onto the critical path for pulling the
> request.
>
> Naming:
>
> 1/ Should it be "apache-jena-osgi" as a delivery module?
>
> 2/ Or have a stable point apache-jena-osgi<type>pom</type> to point to
> "jena-osgi"
>
> 3/ or leave it as jena-osgi and think about the name after 2.13.0 as
> feedback comes in (i.e. a sort of "beta")
>
> If there is an emerging consensus now on a different name, I'll do that else
> put it in as jena-osgi and rename after due consideration.
>
> We can then close:
>
> https://issues.apache.org/jira/browse/JENA-190
>
> Andy
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
On 03/02/15 09:07, Stian Soiland-Reyes wrote:
> then I can put in the pull request.
BTW - if the PR comment has the string "JENA-879" in it, then it should
get referenced by the JIRA. After what seems like a few dropped emails,
we seem to be back connected for github/asf emails so it would be good
to verify that.
Andy
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
Uhm, well must admit I have no clue as to why JNA should be involved in the
first place. If it happens on your machine on two JDKs I guess it could
happen to anyone.
I suggest was try to go with the alternative PAX test I made for JENA-879
instead, even if its not as maintainable
https://github.com/stain/jena/tree/jena-osgi-pax-exam
I just needs to check PAX' massive test dependency list for licensing
issues, then I can put in the pull request.
Not sure if PAX can test with multiple OSGi frameworks, in theory just
adding a second dependency on say Equinox should work.
On 3 Feb 2015 08:49, "Andy Seaborne" <an...@apache.org> wrote:
> On 03/02/15 00:46, Stian Soiland-Reyes wrote:
>
>> Ouch.. seems like a bug in Maven (or more likely) this magic
>> org.rzo.yajsw.os.posix.PosixProcess used by org.everit.osgi.
>>
>> I guess setting it manually with -Djna.nosys=true didn't help either?
>>
>>
>> Another reason to have a quick look at the PAX Exam (JENA-879) - which
>> I'm in the middle of now. It's much more complicated.. :-(
>>
>> On 2 February 2015 at 20:34, Andy Seaborne <an...@apache.org> wrote:
>>
>> -Djna.nosys=true Changes the error ...
>
> (deleting vast amount of my m2 repo does not help)
>
> (2 different traces below, 2 different JVMs:
>
> openjdk-8 with mvn -Djna.nosys=true and with java-8-oracle (with and
> without -D)
> ------------------------------------------------------------------------
> ...
> bsd env NMON=cmdkV
> bsd env EXINIT=set ai aw warn
> bsd env XDG_VTNR=7
> bsd env XDG_RUNTIME_DIR=/run/user/1000
> bsd env HOME=/home/afs
> bsd env GNOME_KEYRING_PID=2785
> /usr/lib/jvm/default-java/bin/java -Djna_tmpdir=/tmp/eosgi-363281406525354060-tmp
> -classpath /mnt/disk1/afs/m2/repo/org/rzo/yajsw/wrapper/11.11/
> wrapper-11.11.jar:/mnt/disk1/afs/m2/repo/net/java/dev/jna/jna/3.4.0/jna-3.4.0.jar
> -Dwrapperx.pipeStreams=true org.rzo.yajsw.os.posix.bsd.AppStarter
> ./runConsole.sh
> started process -1
> exit code bsd process 1
> Exception in thread "main" java.lang.Error:
>
> There is an incompatible JNA native library installed on this system.
> To resolve this issue you may do one of the following:
> - remove or uninstall the offending library
> - set the system property jna.nosys=true
> - set jna.boot.library.path to include the path to the version of the
> jnidispatch library included with the JNA jar file you are using
>
> at com.sun.jna.Native.<clinit>(Native.java:142)
> at org.rzo.yajsw.os.posix.PosixProcess$CLibrary.<clinit>
> (PosixProcess.java:60)
> at org.rzo.yajsw.os.posix.bsd.AppStarter.main(AppStarter.java:14)
> [ERROR] Error reading from input stream. Stopping redirection.
> java.io.IOException: Stream closed
> at java.io.BufferedInputStream.getBufIfOpen(
> BufferedInputStream.java:170)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:336)
> at java.io.FilterInputStream.read(FilterInputStream.java:107)
> at org.everit.osgi.dev.maven.DaemonStreamRedirector$
> PollerRunnable.run(DaemonStreamRedirector.java:62)
> at java.lang.Thread.run(Thread.java:745)
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] Total time: 19.186 s
> [INFO] Finished at: 2015-02-03T08:34:36+00:00
> [INFO] Final Memory: 25M/284M
> [INFO] ------------------------------------------------------------
> ------------
> [ERROR] Failed to execute goal org.everit.osgi.dev:eosgi-
> maven-plugin:3.1.0:integration-test (integration-test) on project
> jena-osgi-test: Test Process of environment felix finished with exit code 1
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/
> MojoExecutionException
> [WARNING] Stopping test process: -1
>
>
> ------------------------------------------------------------------------
> bsd env XDG_RUNTIME_DIR=/run/user/1000
> bsd env HOME=/home/afs
> bsd env GNOME_KEYRING_PID=2785
> /usr/lib/jvm/java-8-oracle//bin/java -Djna_tmpdir=/tmp/eosgi-8727996463447348875-tmp
> -classpath /mnt/disk1/afs/m2/repo/org/rzo/yajsw/wrapper/11.11/
> wrapper-11.11.jar:/mnt/disk1/afs/m2/repo/net/java/dev/jna/jna/3.4.0/jna-3.4.0.jar
> -Dwrapperx.pipeStreams=true org.rzo.yajsw.os.posix.bsd.AppStarter
> ./runConsole.sh
> started process 6882
> calling exec
> openjdk version "1.8.0_40-internal"
> OpenJDK Runtime Environment (build 1.8.0_40-internal-b09)
> OpenJDK 64-Bit Server VM (build 25.40-b13, mixed mode)
> YAJSW: yajsw-stable-11.11
> OS : Linux/3.16.0-28-generic/amd64
> JVM : Oracle Corporation/1.8.0_40-internal//usr/lib/jvm/java-8-openjdk-
> amd64/jre/64
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.rzo.yajsw.boot.WrapperExeBooter.main(WrapperExeBooter.java:43)
> Caused by: java.lang.Error:
>
> There is an incompatible JNA native library installed on this system.
> To resolve this issue you may do one of the following:
> - remove or uninstall the offending library
> - set the system property jna.nosys=true
> - set jna.boot.library.path to include the path to the version of the
> jnidispatch library included with the JNA jar file you are using
>
> at com.sun.jna.Native.<clinit>(Native.java:142)
> at com.sun.jna.Pointer.<clinit>(Pointer.java:42)
> at com.sun.jna.PointerType.<init>(PointerType.java:25)
> at com.sun.jna.ptr.ByReference.<init>(ByReference.java:32)
> at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:22)
> at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:18)
> at org.rzo.yajsw.os.posix.PosixProcess.<init>(PosixProcess.java:43)
> at org.rzo.yajsw.os.posix.OperatingSystemPosix.setWorkingDir(
> OperatingSystemPosix.java:12)
> at org.rzo.yajsw.WrapperExe.main(WrapperExe.java:170)
> ... 5 more
> exit code bsd process 0
> [INFO] Analyzing test results...
> [INFO]
> -------------------------------------------------------
> Test environment finished: equinox
> -------------------------------------------------------
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
> [INFO]
> -------------------------------------------------------
> I N T E G R A T I O N T E S T S ( O S G I)
> -------------------------------------------------------
>
> Results:
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
> [ERROR] Error at test environment 'felix'. Expected test number is 4 while
> 0 number of tests ran.
> [ERROR] Error at test environment 'equinox'. Expected test number is 4
> while 0 number of tests ran.
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] Total time: 7.169 s
> [INFO] Finished at: 2015-02-03T08:41:48+00:00
> [INFO] Final Memory: 25M/580M
> [INFO] ------------------------------------------------------------
> ------------
> [ERROR] Failed to execute goal org.everit.osgi.dev:eosgi-
> maven-plugin:3.1.0:integration-test (integration-test) on project
> jena-osgi-test: Number of expected tests 8 while 0 tests ran. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/
> MojoFailureException
> [WARNING] Stopping test process: 6815
> [WARNING] Stopping test process: 6882
>
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
On 03/02/15 00:46, Stian Soiland-Reyes wrote:
> Ouch.. seems like a bug in Maven (or more likely) this magic
> org.rzo.yajsw.os.posix.PosixProcess used by org.everit.osgi.
>
> I guess setting it manually with -Djna.nosys=true didn't help either?
>
>
> Another reason to have a quick look at the PAX Exam (JENA-879) - which
> I'm in the middle of now. It's much more complicated.. :-(
>
> On 2 February 2015 at 20:34, Andy Seaborne <an...@apache.org> wrote:
>
-Djna.nosys=true Changes the error ...
(deleting vast amount of my m2 repo does not help)
(2 different traces below, 2 different JVMs:
openjdk-8 with mvn -Djna.nosys=true and with java-8-oracle (with and
without -D)
------------------------------------------------------------------------
...
bsd env NMON=cmdkV
bsd env EXINIT=set ai aw warn
bsd env XDG_VTNR=7
bsd env XDG_RUNTIME_DIR=/run/user/1000
bsd env HOME=/home/afs
bsd env GNOME_KEYRING_PID=2785
/usr/lib/jvm/default-java/bin/java
-Djna_tmpdir=/tmp/eosgi-363281406525354060-tmp -classpath
/mnt/disk1/afs/m2/repo/org/rzo/yajsw/wrapper/11.11/wrapper-11.11.jar:/mnt/disk1/afs/m2/repo/net/java/dev/jna/jna/3.4.0/jna-3.4.0.jar
-Dwrapperx.pipeStreams=true org.rzo.yajsw.os.posix.bsd.AppStarter
./runConsole.sh
started process -1
exit code bsd process 1
Exception in thread "main" java.lang.Error:
There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:
- remove or uninstall the offending library
- set the system property jna.nosys=true
- set jna.boot.library.path to include the path to the version of the
jnidispatch library included with the JNA jar file you are using
at com.sun.jna.Native.<clinit>(Native.java:142)
at
org.rzo.yajsw.os.posix.PosixProcess$CLibrary.<clinit>(PosixProcess.java:60)
at org.rzo.yajsw.os.posix.bsd.AppStarter.main(AppStarter.java:14)
[ERROR] Error reading from input stream. Stopping redirection.
java.io.IOException: Stream closed
at
java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170)
at java.io.BufferedInputStream.read(BufferedInputStream.java:336)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at
org.everit.osgi.dev.maven.DaemonStreamRedirector$PollerRunnable.run(DaemonStreamRedirector.java:62)
at java.lang.Thread.run(Thread.java:745)
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 19.186 s
[INFO] Finished at: 2015-02-03T08:34:36+00:00
[INFO] Final Memory: 25M/284M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.everit.osgi.dev:eosgi-maven-plugin:3.1.0:integration-test
(integration-test) on project jena-osgi-test: Test Process of
environment felix finished with exit code 1 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[WARNING] Stopping test process: -1
------------------------------------------------------------------------
bsd env XDG_RUNTIME_DIR=/run/user/1000
bsd env HOME=/home/afs
bsd env GNOME_KEYRING_PID=2785
/usr/lib/jvm/java-8-oracle//bin/java
-Djna_tmpdir=/tmp/eosgi-8727996463447348875-tmp -classpath
/mnt/disk1/afs/m2/repo/org/rzo/yajsw/wrapper/11.11/wrapper-11.11.jar:/mnt/disk1/afs/m2/repo/net/java/dev/jna/jna/3.4.0/jna-3.4.0.jar
-Dwrapperx.pipeStreams=true org.rzo.yajsw.os.posix.bsd.AppStarter
./runConsole.sh
started process 6882
calling exec
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b09)
OpenJDK 64-Bit Server VM (build 25.40-b13, mixed mode)
YAJSW: yajsw-stable-11.11
OS : Linux/3.16.0-28-generic/amd64
JVM : Oracle
Corporation/1.8.0_40-internal//usr/lib/jvm/java-8-openjdk-amd64/jre/64
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.rzo.yajsw.boot.WrapperExeBooter.main(WrapperExeBooter.java:43)
Caused by: java.lang.Error:
There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:
- remove or uninstall the offending library
- set the system property jna.nosys=true
- set jna.boot.library.path to include the path to the version of the
jnidispatch library included with the JNA jar file you are using
at com.sun.jna.Native.<clinit>(Native.java:142)
at com.sun.jna.Pointer.<clinit>(Pointer.java:42)
at com.sun.jna.PointerType.<init>(PointerType.java:25)
at com.sun.jna.ptr.ByReference.<init>(ByReference.java:32)
at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:22)
at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:18)
at org.rzo.yajsw.os.posix.PosixProcess.<init>(PosixProcess.java:43)
at
org.rzo.yajsw.os.posix.OperatingSystemPosix.setWorkingDir(OperatingSystemPosix.java:12)
at org.rzo.yajsw.WrapperExe.main(WrapperExe.java:170)
... 5 more
exit code bsd process 0
[INFO] Analyzing test results...
[INFO]
-------------------------------------------------------
Test environment finished: equinox
-------------------------------------------------------
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
-------------------------------------------------------
I N T E G R A T I O N T E S T S ( O S G I)
-------------------------------------------------------
Results:
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[ERROR] Error at test environment 'felix'. Expected test number is 4
while 0 number of tests ran.
[ERROR] Error at test environment 'equinox'. Expected test number is 4
while 0 number of tests ran.
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 7.169 s
[INFO] Finished at: 2015-02-03T08:41:48+00:00
[INFO] Final Memory: 25M/580M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.everit.osgi.dev:eosgi-maven-plugin:3.1.0:integration-test
(integration-test) on project jena-osgi-test: Number of expected tests 8
while 0 tests ran. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[WARNING] Stopping test process: 6815
[WARNING] Stopping test process: 6882
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
Ouch.. seems like a bug in Maven (or more likely) this magic
org.rzo.yajsw.os.posix.PosixProcess used by org.everit.osgi.
I guess setting it manually with -Djna.nosys=true didn't help either?
Another reason to have a quick look at the PAX Exam (JENA-879) - which
I'm in the middle of now. It's much more complicated.. :-(
On 2 February 2015 at 20:34, Andy Seaborne <an...@apache.org> wrote:
> On 02/02/15 11:33, Stian Soiland-Reyes wrote:
>>>
>>> 1/ Build failure
>>> >
>>> >jena-osgi-test fails the build in step "verify"
>>> >
>>> >tried: java-8-openjdk and java-7-openjdk
>>> >
>>> >------------------------
>>> >Exception in thread "main" java.lang.Error:
>>> >
>>> >There is an incompatible JNA native library installed on this system.
>>> >To resolve this issue you may do one of the following:
>>> > - remove or uninstall the offending library
>>> > - set the system property jna.nosys=true
>>> > - set jna.boot.library.path to include the path to the version of the
>>> > jnidispatch library included with the JNA jar file you are using
>>> >
>>> > at com.sun.jna.Native.<clinit>(Native.java:142)
>>
>> I'm not sure what JNl library you have, possibly some OS X thing?
>>
>> I'll find out how we can set this jna.nosys property, as it should not
>> be of any worry for this testing.
>>
>> (but it should be of worry if you made an OSGi application which
>> needed that JNI library! :))
>>
>> Do you know if this error is thrown from the Felix or the Equinox
>> test? (As it tests both frameworks)
>>
>>
> (HTML for the formatting)
>
> After #23 I still get the error. The output is:
>
> ....
> constituent[36]:
> file:/home/afs/sys/apache-maven/lib/aether-util-0.9.0.M2.jar
> constituent[37]:
> file:/home/afs/sys/apache-maven/lib/wagon-http-shared-2.6.jar
> constituent[38]:
> file:/home/afs/sys/apache-maven/lib/org.eclipse.sisu.plexus-0.0.0.M5.jar
> constituent[39]: file:/home/afs/sys/apache-maven/conf/logging/
> ---------------------------------------------------
> Exception in thread "main" java.lang.Error:
>
> There is an incompatible JNA native library installed on this system.
> To resolve this issue you may do one of the following:
> - remove or uninstall the offending library
> - set the system property jna.nosys=true
> - set jna.boot.library.path to include the path to the version of the
> jnidispatch library included with the JNA jar file you are using
>
> at com.sun.jna.Native.<clinit>(Native.java:142)
> at com.sun.jna.Pointer.<clinit>(Pointer.java:42)
> at com.sun.jna.PointerType.<init>(PointerType.java:25)
> at com.sun.jna.ptr.ByReference.<init>(ByReference.java:32)
> at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:22)
> at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:18)
> at org.rzo.yajsw.os.posix.PosixProcess.<init>(PosixProcess.java:43)
> at org.rzo.yajsw.os.posix.bsd.BSDProcess.<init>(BSDProcess.java:21)
> at
> org.everit.osgi.dev.maven.IntegrationTestMojo.execute(IntegrationTestMojo.java:393)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>
> after which maven crashes out and I get the command line prompt back. No
> trailing maven [INFO] messages at all.
>
> Andy
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
On 02/02/15 11:33, Stian Soiland-Reyes wrote:
>> 1/ Build failure
>> >
>> >jena-osgi-test fails the build in step "verify"
>> >
>> >tried: java-8-openjdk and java-7-openjdk
>> >
>> >------------------------
>> >Exception in thread "main" java.lang.Error:
>> >
>> >There is an incompatible JNA native library installed on this system.
>> >To resolve this issue you may do one of the following:
>> > - remove or uninstall the offending library
>> > - set the system property jna.nosys=true
>> > - set jna.boot.library.path to include the path to the version of the
>> > jnidispatch library included with the JNA jar file you are using
>> >
>> > at com.sun.jna.Native.<clinit>(Native.java:142)
> I'm not sure what JNl library you have, possibly some OS X thing?
>
> I'll find out how we can set this jna.nosys property, as it should not
> be of any worry for this testing.
>
> (but it should be of worry if you made an OSGi application which
> needed that JNI library! :))
>
> Do you know if this error is thrown from the Felix or the Equinox
> test? (As it tests both frameworks)
>
>
(HTML for the formatting)
After #23 I still get the error. The output is:
....
constituent[36]:
file:/home/afs/sys/apache-maven/lib/aether-util-0.9.0.M2.jar
constituent[37]:
file:/home/afs/sys/apache-maven/lib/wagon-http-shared-2.6.jar
constituent[38]:
file:/home/afs/sys/apache-maven/lib/org.eclipse.sisu.plexus-0.0.0.M5.jar
constituent[39]: file:/home/afs/sys/apache-maven/conf/logging/
---------------------------------------------------
Exception in thread "main" java.lang.Error:
There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:
- remove or uninstall the offending library
- set the system property jna.nosys=true
- set jna.boot.library.path to include the path to the version of the
jnidispatch library included with the JNA jar file you are using
at com.sun.jna.Native.<clinit>(Native.java:142)
at com.sun.jna.Pointer.<clinit>(Pointer.java:42)
at com.sun.jna.PointerType.<init>(PointerType.java:25)
at com.sun.jna.ptr.ByReference.<init>(ByReference.java:32)
at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:22)
at com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:18)
at org.rzo.yajsw.os.posix.PosixProcess.<init>(PosixProcess.java:43)
at org.rzo.yajsw.os.posix.bsd.BSDProcess.<init>(BSDProcess.java:21)
at
org.everit.osgi.dev.maven.IntegrationTestMojo.execute(IntegrationTestMojo.java:393)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
after which maven crashes out and I get the command line prompt back.
No trailing maven [INFO] messages at all.
Andy
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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 <an...@apache.org> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
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?
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.
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 ... :)
On 2 February 2015 at 15:32, Andy Seaborne <an...@apache.org> 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 <an...@apache.org> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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
>>
>>
>>
>>
>
>
>
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
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).
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 <an...@apache.org> 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
>
>
>
>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 2 February 2015 at 13:11, Andy Seaborne <an...@apache.org> wrote:
> 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.
Some relevant LEGAL issues (which don't really clarify as they ask for
the FAQ to be updated, but that wasn't done)
https://issues.apache.org/jira/browse/LEGAL-207
https://issues.apache.org/jira/browse/LEGAL-153
So although it "should" be OK for test runtime only (as our test-code
only compiles/binds with junit, not the eosgi-junit-runner), the best
long-term is probably to explore the pax-exam solution suggested by
Benson.
There's always the risk that someone down-stream will find that OSGi
lib/ auto-packaging made by eosgi useful, and unintentionally add it
to their product without considering the LGPL license.
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
On 02/02/15 14:11, Stian Soiland-Reyes wrote:
> Tracked as:
> https://issues.apache.org/jira/browse/JENA-879
> (I'm unable to assign it to myself in Jira - anyone else want to have a go?:-)
There are two roles here - the committer who lets it into the code base
the doer who makes the contribution. "assigned" is usually the
committer (=verifier).
Andy
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks for the hint, Benson! I had looked at PAX before without
figuring it out, but this time I found more documentation, and it
looks like it is definitely worth a try (even if it has a bit more
heavyweight setup than eosgi).
Tracked as:
https://issues.apache.org/jira/browse/JENA-879
(I'm unable to assign it to myself in Jira - anyone else want to have a go? :-)
I don't think this should be a blocker for 2.13.0 as we can leave
jena-osgi-test optional on the apache-release profile.
On 2 February 2015 at 13:14, Benson Margulies <bi...@gmail.com> wrote:
> The maven-bundle-plugin + the pax-exam tools make for a full AL
> solution to making bundles and testing bundles.
>
> See, for example:
>
> https://github.com/basis-technology-corp/tcl-regex-java
>
> On Mon, Feb 2, 2015 at 8:11 AM, Andy Seaborne <an...@apache.org> 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
>>
>>
>>
>>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Benson Margulies <bi...@gmail.com>.
The maven-bundle-plugin + the pax-exam tools make for a full AL
solution to making bundles and testing bundles.
See, for example:
https://github.com/basis-technology-corp/tcl-regex-java
On Mon, Feb 2, 2015 at 8:11 AM, Andy Seaborne <an...@apache.org> 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
>
>
>
>
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
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
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <so...@cs.manchester.ac.uk>.
As do I!
I added to the pull request
<systemProperties>
<!-- We don't care if there are any JNAs -->
<jna.nosys>true</jna.nosys>
</systemProperties>
to both <enviroment> according to
http://www.everit.org/eosgi-maven-plugin/#environment_settings
Could you test if it works now?
On 2 February 2015 at 11:46, Andy Seaborne <an...@apache.org> wrote:
> On 02/02/15 11:33, Stian Soiland-Reyes wrote:
>>
>> I'm not sure what JNl library you have, possibly some OS X thing?
>
>
> I'm on Ubuntu 14.10
>
> Andy
>
--
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
On 02/02/15 11:33, Stian Soiland-Reyes wrote:
> I'm not sure what JNl library you have, possibly some OS X thing?
I'm on Ubuntu 14.10
Andy
Re: Jena OSGi pull request
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 1 February 2015 at 13:12, Andy Seaborne <an...@apache.org> wrote:
> Current status:
>
> * Pull request merged
Thanks!
> * jena-osgi-test commented out of the build
> * Fatal problem building
> * LGPL issue (not an issue ATM as not in the build)
Oh no :-(
> 1/ Build failure
>
> jena-osgi-test fails the build in step "verify"
>
> tried: java-8-openjdk and java-7-openjdk
>
> ------------------------
> Exception in thread "main" java.lang.Error:
>
> There is an incompatible JNA native library installed on this system.
> To resolve this issue you may do one of the following:
> - remove or uninstall the offending library
> - set the system property jna.nosys=true
> - set jna.boot.library.path to include the path to the version of the
> jnidispatch library included with the JNA jar file you are using
>
> at com.sun.jna.Native.<clinit>(Native.java:142)
I'm not sure what JNl library you have, possibly some OS X thing?
I'll find out how we can set this jna.nosys property, as it should not
be of any worry for this testing.
(but it should be of worry if you made an OSGi application which
needed that JNI library! :))
Do you know if this error is thrown from the Felix or the Equinox
test? (As it tests both frameworks)
> 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.
This plugin basically sets up the target/eosgi-dist/ startup folders
for the OSGi frameworks Equinox (by Eclipse) and Felix (Apache), then
installs the bundle to be tested and its dependencies into their lib/
folders.
The plugin then listens for the results of that junit-runner, which is
executed within the OSGi framework.
It should in theory be possible to set up the OSGi framework manually
(only one of them then) without this plugins - this would take some
more time to develop. The only hard bit is communicating our of the
OSGi framework to say a test has failed - perhaps a rough
System.exit(-1).
If you are not happy to keep it under -Pcomplete, I suggest just doing
it by -Papache-release (as in my new pull request).
I can modify https://cwiki.apache.org/confluence/display/JENA/Release+Process
to describe this bit - as it could cause delays in making a release
later.
> It means an end-user could not build jena from source without that
> dependency (the build would fail). It is not "provided".
It is needed only for the test to work at OSGi runtime, e.g. for the
Maven plugin to be able to execute the JUnit test. So it's a
dependency of the jena-osgi-test bundle which nobody else would use
outside this test.
We can in theory change to <scope>provided</scope> and modify the
maven plugins' configs to pick it up anyway - would that make any
difference?
You shouldn't normally need to run jena-osgi-test unless you are
preparing a Jena release or messing about with the dependencies - it
would basically just test that the jena-osgi will load and run within
OSGi - and so should hopefully fail if we have changed upstream
dependencies.
I have thus modified this to be only included in -Papache-release
(See https://github.com/apache/jena/pull/21 from above)
> and some questions thrown up by merging the contribution:
>
> Q1/
> Why are the dependencies of jena-core etc in jena-osgi "provided"?
This is mainly a question of style. Semantically speaking they are in
scope "provided" because they are not dependencies of the jena-osgi
module after it has been built - the jena-core etc. are shadowed
within the jena-osgi.jar. They are not in scope "provided" meaning
that you have to provide them later. Maven's understanding of
"provided" is that downstream packages simply ignore it - typically
this is used with servlet-api, though.
They are however needed for building (e.g. for the shadowing to pick
it up). The only <scope>compile</scope> dependencies declared in the
final POM are those needed at OSGi runtime, e.g.
other OSGi bundles.
(You can't make up your own scope names in Maven. An alternative which
I have used before in another setting is <scope>test</scope> (as there
are no tests directly here) - but it could be just as confusing if you
read it literally.. )
Using scope=provided means that Maven usage of the bundle JAR (e.g. as
in jena-osgi-test) won't also get duplicate JARs of the non-bundled
versions of Jena - yet will automatically depend on the external OSGi
bundles that jena-osgi relies on.
This shadowing of org.apache.jena.* should mean that a OSGi Maven
project can depend on only jena-osgi (just like apache-jena-libs) for
compile purposes as well - as demonstrated in jena-osgi-test - and
thus won't need to do their own <scope>provided</scope> tricks.
For an example of how it is otherwise - see how I struggle to depend
on the httpclient-osgi which has used <scope>compile<scope> for the
shadowed JARs:
https://github.com/apache/jena/blob/b01f6a7e0e49e3b50f6bca5e46486bb3983639fe/jena-osgi/pom.xml#L93
and ironically - its dependency on httpcore-osgi is NOT declared, so I
have to depend on that manually as well below, with similar
exclusions.
(whenever I get that time machine I should talk about this with the
Felix and httpcore guys..)
Basically having such exclusions are very fragile, because there could
come in a 5th dependency later that also needs to be shadowed. So I
wouldn't want jena-osgi Maven users to face that challenge.
But it is worth checking up with the Felix list why common practice is
to not use <scope>provided</scope> - one would assume bundles made
with maven-bundle-plugin should be compatible with other Maven
projects using maven-bundle-plugin :-)
> Q2/
>
> There is a note about a change for when we use jsonld-java 0.5.1 ... and we
> now are. Should that change be made? Has it been tested?
I did test that, and jsonld-java >= 0.5.1 is NOT in
<scope>provided</scope> - so it's depended on as an OSGi bundle, which
worked perfectly.
That whole comment section should thus be removed - the jackson
bundles are pulled in correctly.
My apologies for not cleaning that up. Fixed in
https://github.com/apache/jena/pull/21
> Q3/
>
> Why was there a separate <modules> for jena-osgi-test?
> jena-osgi isn't in all profiles.
> (moved to next to jena-osgi)
jena-osgi-test should only be needed in the same profile as jena-osgi,
and probably ONLY in the apache-release profile.
I think it makes sense to keep it in the "complete" profile - similar
to apache-jena dist.
jena-osgi-test must be in a separate module in order to test that the
jena-osgi bundle from a client perspective. Otherwise I would mess up
the dependency handling and it could just work "by accident" only in
that test.
> Q4/
> We have a style of nesting directories (see Elephas, jena-jdbc, Fuseki2).
>
> Can we put jena-osgi-test inside jena-osgi?
While I might not like that style, I can agree on the argument -
specially as jena-osgi-test is never useful separately, and we only
have a single git repository.
To do this you would however need a second module name, e.g.
jena-osgi-bundle - but the common naming style for these kind of
bundles are $product-bundle (e.g. as httpcore-osgi). Perhaps call the
top-folder for apache-jena-osgi? That hints of it also being another
"dist" thing.
Implemented in the pull request above.
> Q5/ It says:
>
> <timeout>150000</timeout><!-- 15000ms = 15s -->
>
> no!
>
> 150000 is 150s -- which is right, code or comment?
It should be set to 15s. Comment wins!
Also fixed in the pull request.
> Q6/
> 3/ Build warnings : do they matter?
>
> If not, can they be suppressed?
>
> [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Unused
> Private-Package instructions, no such package(s) on the class path: [!*]
> [WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT : Export
> com.hp.hpl.jena.datatypes.xsd, has 1, private references
> [org.apache.xerces.impl.dv],
>
> and 8 others about private references
They do matter a bit - as it makes a noisy/fragile OSGi package.
I don't think we should surpress them as we should try to get rid of
all of them for Jena 3, when we have the ability to (slightly) tweak
Jena's package organization.
Some of these should be fixable before that.
Not sure why "!*" leaked out as a literal, this should have been
interpreted by the maven-bundle-plugin (as it's his default!). It
might mean that the plugin found no private packages - even though it
probably should have.
I am not sure which of Jena's packages can be considered private. I
struggled with that even within the jena-iri package..
The default from maven-bundle-plugin should be something like *.impl,
but he might think otherwise if he sees such classes/interfaces leaked
through the API signatures of the non-impl packages.
Not sure why com.hp.hpl.jena.datatypes.xsd would depend on
org.apache.xerces.impl.dv - depending on impl* is a generally no-no:
stain@biggie-utopic:~/src/jena/jena-core/src/main/java/com/hp/hpl/jena/datatypes$
grep -r xerces.*impl .
./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.* ;
./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.util.Base64 ;
./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.util.HexBin ;
./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.xs.DecimalDV ;
./xsd/XSDDatatype.java:import org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl ;
./xsd/XSDDatatype.java:import
org.apache.xerces.impl.validation.ValidationState ;
./xsd/XSDhexBinary.java:import org.apache.xerces.impl.dv.util.HexBin ;
./xsd/XSDbase64Binary.java:import org.apache.xerces.impl.dv.util.Base64 ;
./xsd/impl/XSDGenericType.java:import org.apache.xerces.impl.dv.XSSimpleType;
Some of these (base64) are available through more official packages -
org.apache.commons.codec.binary.Base64 comes to mind.
https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html
https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Hex.html
I've raised this as a bug and will try to have a look at it later -
should we delay the switch of implementation here until after the
2.13.0 release?
https://issues.apache.org/jira/browse/JENA-878
As we bundle xerces as a shadowed JAR rather than depend on an OSGi
version of it, then it should still work anyway - until we upgrade
xerces and they change/remove those.
Perhaps we should also modify
https://github.com/apache/jena/blob/master/jena-osgi-test/src/main/java/org/apache/jena/osgi/test/JenaOSGITestImpl.java#L72
to test XSDDatatype to be sure.
The warnings about org.xml.sax, javax.xml.stream, org.w3c.dom
javax.xml.datatype, are strange, as they are built into Java 6. They
should be suppressible somehow.
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Jena OSGi pull request
Posted by Andy Seaborne <an...@apache.org>.
Current status:
* Pull request merged
* jena-osgi-test commented out of the build
* Fatal problem building
* LGPL issue (not an issue ATM as not in the build)
1/ Build failure
jena-osgi-test fails the build in step "verify"
tried: java-8-openjdk and java-7-openjdk
------------------------
Exception in thread "main" java.lang.Error:
There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:
- remove or uninstall the offending library
- set the system property jna.nosys=true
- set jna.boot.library.path to include the path to the version of the
jnidispatch library included with the JNA jar file you are using
at com.sun.jna.Native.<clinit>(Native.java:142)
...
------------------------
2/ There is a LGPL dependency (scope test) which needs investigation.
(I would have appreciated that having been pointed out first)
It means an end-user could not build jena from source without that
dependency (the build would fail). It is not "provided".
and some questions thrown up by merging the contribution:
Q1/
Why are the dependencies of jena-core etc in jena-osgi "provided"?
Q2/
There is a note about a change for when we use jsonld-java 0.5.1 ... and
we now are. Should that change be made? Has it been tested?
Q3/
Why was there a separate <modules> for jena-osgi-test?
jena-osgi isn't in all profiles.
(moved to next to jena-osgi)
Q4/
We have a style of nesting directories (see Elephas, jena-jdbc, Fuseki2).
Can we put jena-osgi-test inside jena-osgi?
Q5/ It says:
<timeout>150000</timeout><!-- 15000ms = 15s -->
no!
150000 is 150s -- which is right, code or comment?
Q6/
3/ Build warnings : do they matter?
If not, can they be suppressed?
[WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT :
Unused Private-Package instructions, no such package(s) on the class
path: [!*]
[WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.12.2-SNAPSHOT :
Export com.hp.hpl.jena.datatypes.xsd, has 1, private references
[org.apache.xerces.impl.dv],
and 8 others about private references
Andy