On 1 February 2015 at 13:12, Andy Seaborne <[email protected]> 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
