I'll change my vote to a -0 as an ARQ.init(); is sufficient to fix it for me. Nevertheless, not the kind of bug I would expect from a patch update..
On 7 November 2016 at 00:25, Stian Soiland-Reyes <[email protected]> wrote: > My problem seems to be with early access of NodeFactory and then > org.apache.jena.riot.out.NodeFmtLib, e.g. > > @Test > public void testName() throws Exception { > Node node = NodeFactory.createLiteral("Hello world", "en"); > assertEquals("\"Hello world\"@en", NodeFmtLib.str(node)); > } > > Fails with: > > java.lang.ExceptionInInitializerError > at org.apache.jena.riot.out.NodeFmtLib.<clinit>(NodeFmtLib.java:55) > at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15) > 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:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: org.apache.jena.sparql.ARQException: Context key is null > at org.apache.jena.sparql.util.Context._put(Context.java:102) > at org.apache.jena.sparql.util.Context.set(Context.java:94) > at > org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74) > at > org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48) > at org.apache.jena.query.ARQ.init(ARQ.java:592) > at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29) > at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119) > at java.util.ArrayList.forEach(ArrayList.java:1249) > at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194) > at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171) > at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117) > at org.apache.jena.sparql.ARQConstants.<clinit>(ARQConstants.java:35) > ... 25 more > > > > On 7 November 2016 at 00:05, Stian Soiland-Reyes <[email protected]> wrote: >> Thanks for putting together a 3.1.1 RC! >> >> >> I'm afraid my vote is: >> >> -1 (non-binding) >> >> because of broken initializers and confusing LICENSE in source archive. >> >> >> Checked: >> >> + GPG signatures >> + source zip matches git commit; adds only (empty) DEPENDENCIES and >> dependency-reduced-pom.xml >> - Hashes - you didn't provide dist svn revision or its sha1 hashes, >> I'll assume rev 16841 >> - repository JARs/POMs; broken initializers? >> - LICENSE; confusing, see below >> 0 NOTICE; see below >> +1 binaries/apache-jena-3.1.1.tar.gz riot tested with json-ld >> +1 binaries/apache-jena-fuseki-2.4.1.tar.gz tested with tdb, json-ld >> upload and sparql >> +1 mvn install -DskipTests=true >> +1 mvn clean install (50 minutes!) >> -1 outdated jackson >> -1 wrong semantic versioning >> >> >> I am failing this RC as I was unable to use the build artifacts from >> Commons RDF 0.3.0-SNAPSHOT (master), which works fine with Jena 3.1.0. >> >> This seems to be the case both with jena-osgi or with apache-jena-libs >> <dependency> >> >> To replicate, try do "mvn clean install -l api,simple,jena" in >> https://github.com/stain/incubator-commonsrdf/tree/jena-3.1.1-rc2 >> >> Something wrong with the initializers or an internal dependency >> missing from a pom.xml somewhere..? I'll see what I can figure out >> and raise in JIRA. >> >> >> JSON-LD is working, however in jena-parent/pom.xm >> >> <!-- Used by jena-osgi and must be in-step with jsonldjava --> >> <ver.jackson>2.6.3</ver.jackson> >> >> but the newer jsonld-java 0.8.4 (claims to) need jackson 2.7.4: >> https://github.com/jsonld-java/jsonld-java/blob/v0.8.3/pom.xml#L44 >> >> This might break under OSGi (but I haven't tested, so not a blocker). >> >> >> >> >> >> >> T E S T S >> ------------------------------------------------------- >> Running org.apache.commons.rdf.jena.TestGraphJena >> Tests run: 10, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 7.327 >> sec <<< FAILURE! - in org.apache.commons.rdf.jena.TestGraphJena >> addBlankNodesFromMultipleGraphs(org.apache.commons.rdf.jena.TestGraphJena) >> Time elapsed: 6.657 sec <<< ERROR! >> java.lang.ExceptionInInitializerError >> Caused by: org.apache.jena.sparql.ARQException: Context key is null >> >> whyJavaStreamsMightNotTakeOverFromSparql(org.apache.commons.rdf.jena.TestGraphJena) >> Time elapsed: 0.041 sec <<< ERROR! >> java.lang.NoClassDefFoundError >> Caused by: java.lang.NoClassDefFoundError: Could not initialize class >> org.apache.jena.riot.out.NodeFmtLib >> >> Running org.apache.commons.rdf.jena.TestJenaGraphToCommonsRDFGraph >> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.336 >> sec <<< FAILURE! - in >> org.apache.commons.rdf.jena.TestJenaGraphToCommonsRDFGraph >> jenaToCommonsRDF(org.apache.commons.rdf.jena.TestJenaGraphToCommonsRDFGraph) >> Time elapsed: 0.314 sec <<< ERROR! >> java.lang.NoClassDefFoundError: Could not initialize class >> org.apache.jena.sparql.ARQConstants >> at >> org.apache.commons.rdf.jena.TestJenaGraphToCommonsRDFGraph.jenaToCommonsRDF(TestJenaGraphToCommonsRDFGraph.java:63) >> >> >> By changing to jena-osgi 3.1.1 in >> https://github.com/apache/incubator-commonsrdf (jena.version in >> pom.xml) >> and adding >> https://repository.apache.org/content/repositories/orgapachejena-1015/ >> as staging repository. >> >> >> >> I get the same errors if instead if instead of jena-osgi I try to use: >> >> <dependency> >> <groupId>org.apache.jena</groupId> >> <artifactId>apache-jena-libs</artifactId> >> <version>${jena.version}</version> >> <type>pom</type> >> </dependency> >> >> >> And again the same error if I use the locally mvn install-ed JARs. >> >> >> Is an internal dependency missing? >> >> >> Not sure if this warning when building jena-osgi is related: >> >> >> [WARNING] Bundle org.apache.jena:jena-osgi:bundle:3.1.1 : Split >> package, multiple jars provide the same package:org/apache/jena/system >> Use Import/Export Package directive >> -split-package:=(merge-first|merge-last|error|first) to get rid of >> this warning >> Package found in [Jar:jena-arq, Jar:jena-core] >> Class path [Jar:., Jar:jena-arq, Jar:jena-core, >> Jar:xercesImpl, Jar:commons-cli, Jar:jena-base, Jar:collection, >> Jar:org.apache.servicemix.bundles.xerces, Jar:xml-apis, >> Jar:jena-shaded-guava, Jar:guava, Jar:jena-tdb, Jar:jena-iri, >> Jar:httpclient-osgi, Jar:httpcore-osgi, Jar:jsonld-java, >> Jar:jackson-core, Jar:jackson-databind, Jar:jackson-annotations, >> Jar:commons-io, Jar:commons-csv, Jar:libthrift, Jar:jcl-over-slf4j, >> Jar:slf4j-api, Jar:commons-lang3, Jar:org.osgi.core, >> Jar:slf4j-log4j12, Jar:log4j] >> [WARNING] Bundle org.apache.jena:jena-osgi:bundle:3.1.1 : Unused >> Import-Package instructions: [org.apache.xml.*] >> >> >> >> Another thing, LICENSE file of jena-3.1.1-source-release.zip says >> >> >>> The following files contain code contributed by Plugged In Software: >>> >>> src/main/java/org/apache/jena/rdf/arp/ExtendedHandler.java >>> src/main/java/org/apache/jena/rdf/arp/impl/XMLHandler.java >>> src/main/java/org/apache/jena/rdf/arp/ARP.java >> >> but the correct file paths are presumably these under jena-core/ and >> in different packages: >> >> jena-core/src/main/java/org/apache/jena/rdfxml/xmlinput/ExtendedHandler.java >> jena-core/src/main/java/org/apache/jena/rdfxml/xmlinput/impl/XMLHandler.java >> jena-core/src/main/java/org/apache/jena/rdfxml/xmlinput/ARP.java >> >> I wonder why these files have BOTH the Apache license and BSD >> license.. particularly with the confusing "see end of line for BSD >> license" comment at the top. I presume this means they also include >> substantial ASF contributions (beyond adding a header) as otherwise >> the policy normally is to leave the file at its original license? Why >> is the BSD license at the end? >> >> This is not a showstopper for this RC as the files (which have the >> same filename, just wrong path) also include the BSD license text, >> just some paths to fix for later. >> >> >> >> However I am not to keen with the very end of the LICENSE file: >> >>> - - - - - - - - - - - - - - - - - - - - - - - >>> >>> Copyright (c) 2004-2009 Mort Bay Consulting Pty. Ltd. >>> >>> All rights reserved. This program and the accompanying materials >>> are made available under the terms of the Eclipse Public License v1.0 >>> and Apache License v2.0 which accompanies this distribution. >>> >>> The Eclipse Public License is available at >>> http://www.eclipse.org/legal/epl-v10.html >>> The Apache License v2.0 is available at >>> http://www.opensource.org/licenses/apache2.0.php >> >> >> >> This sounds wrong to me. What is it that is (c) 2004-2009 Mort Bay? >> And where is the Eclipse Public License "which accompanies this >> distribution"? Why is the Apache license linked to at >> www.opensource.org rather than the text above in the file or the >> canonical www.apache.org/licenses/LICENSE-2.0? Also if it is here >> used only under the Apache license, why do we also say that "this >> program" (Jena?) is under Eclipse Public License, when presumably only >> some of the files are? >> >> >> Related in NOTICE: >> >>> Apache Jena >>> Copyright 2011, 2012, 2013, 2014, 2015, 2016 The Apache Software Foundation >>> .. >>> - Copyright 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 >>> Hewlett-Packard Development Company, LP >> >> >> I guess no need to list all the years, 2011-2016 and 2001-2009 would suffice. >> >>> This product includes software developed by >>> PluggedIn Software under a BSD license. >> >> Was this originally in NOTICE pre Apache? It should not need to be >> listed in NOTICE as well - particularly as "includes software" is >> all-inclusive - if it's just those three files then without noting >> that, these notice line has to be propagated by downstream even when >> they are irrelevant. >> >> >> >> Just another plea for a bit of Semantic Versioning.. http://semver.org/ >> >> >> I ran japicmp on jena-core, which highlights these potential breaking >> changes from 3.1.0: >> >> https://gist.github.com/stain/175df0c62d6cac451d35ab11f90a7ab6 >> >> Do we have a changelog for these..? (Ignoring impls) >> >> I would have called this version 3.2.0 instead - I remember several >> times when a "patch" update of Jena has lots of big changes in other >> code; I guess after 6 months of hard work we can't aim for patch >> compatibility anymore so it's just fair to go for 3.2.0 even if >> there's nothing new politically. >> >> >> >> >> >> For archival purposes, these are the sha1sums from dist 16841 which I >> assume are the ones that are candidates of this vote. >> >> 153605cbfc13f399cb362bec59fee1d08b640e67 >> source/jena-3.1.1-source-release.zip >> 57a2b65ddcc01d386d09dceaf576188f49c66fe0 binaries/apache-jena-3.1.1.zip >> 45015ea71a312d92a0b23a454b36aed8ea46e3e2 >> binaries/apache-jena-fuseki-2.4.1.zip >> 3adcaf35eb0d9be850cfa2f9e4fae7e5db6ac9b6 >> binaries/jena-fuseki1-1.4.1-distribution.zip >> a47ede6aad31cde586f33a0b22389bff91257543 binaries/apache-jena-3.1.1.tar.gz >> d9d73ef66eaec85af1f7939aaa79bf8546a0a493 >> binaries/apache-jena-fuseki-2.4.1.tar.gz >> 70bf6c6ed2534da9b13a979cdeb5caf557552d68 >> binaries/jena-fuseki1-1.4.1-distribution.tar.gz >> >> >> Build tested on Ubuntu 16.04 x64 with: >> >> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; >> 2015-11-10T16:41:47+00:00) >> Maven home: /home/stain/software/maven >> Java version: 1.8.0_91, vendor: Oracle Corporation >> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre >> Default locale: en_GB, platform encoding: UTF-8 >> OS name: "linux", version: "4.4.0-45-generic", arch: "amd64", family: "unix" >> >> On 4 November 2016 at 22:43, Andy Seaborne <[email protected]> wrote: >>> >>> Hi, >>> >>> Here is a vote on a release of Jena 3.1.1 >>> (with Fuseki 2.4.1 and Fuseki 1.4.1). >>> >>> This is the second proposed candidate for this release. >>> >>> ** My signing key has changed - to verify, use the key in ** >>> ** https://svn.apache.org/repos/asf/jena/dist/KEYS ** >>> ** for [email protected]. ** >>> >>> * Dependency changes: >>> >>> New module: >>> jena-fuseki2/jena-fuseki-embedded >>> >>> Updates: >>> com.github.jsonld-java:jsonld-java 0.7.0 -> 0.8.3 >>> >>> org.apache.httpcomponents:httpClient 4.2.6 -> 4.5.2 >>> org.apache.httpcomponents:httpCache 4.2.6 -> 4.5.2 >>> org.apache.httpcomponents:httpCore 4.2.5 -> 4.4.4 >>> >>> com.jayway.awaitility:awaitility 1.6.4 -> 1.7.0 >>> com.spatial4j:spatial4j 0.4.1 -> 0.5 >>> org.slf4j:* 1.7.20 -> 1.7.21 >>> commons-codec:commons-codec 1.9 -> 1.10 >>> org.apache.commons:commons-collections4 4.0 -> 4.1 >>> org.apache.commons:commons-csv 1.0 -> 1.3 >>> org.apache.commons:commons-lang3 3.3.2 -> 3.4 >>> org.apache.thrift:libthrift 0.9.2 -> 0.9.3 >>> org.apache.mrunit:mrunit 1.0.0 -> 1.1.0 >>> com.github.rvesse:airline 2.1.0 -> 2.1.1 >>> >>> >>> Key features of the release: >>> >>> * Improve JSON-LD output >>> JENA-1208 - François-Paul Servant >>> http://jena.staging.apache.org/documentation/io/rdf-output.html#json-ld >>> >>> * Completed F&O XPath3 functions >>> JENA-508 - Alessandro Seganti >>> >>> * ComplexPhraseQueryParser >>> JENA-1180 - Andrew Dolby >>> >>> * Additional vocabularies (DCAT, VoID, ROV, ORG) >>> JENA-1206 - Bart Hanssens >>> >>> * Improvement to the Fuseki service script for RHEL/Centos 6. >>> JENA-1219 - Dan Pritts >>> >>> * ORDER BY now cancelable. >>> >>> * Txn : a highlevel API for working with transactions >>> http://jena.staging.apache.org/documentation/txn/txn.html >>> >>> * Embedded Fuseki >>> http://jena.staging.apache.org/documentation/fuseki2/fuseki-embedded.html >>> >>> * Property path speed ups (JENA-1195) >>> >>> * Upgrade to Apache HttpClient v4.3 API >>> => auth changes cause API changes. >>> >>> >>> Everyone, not just committers, is invited to test and vote. >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachejena-1015/ >>> >>> Proposed dist/ area: >>> https://dist.apache.org/repos/dist/dev/jena/ >>> >>> Keys: >>> https://svn.apache.org/repos/asf/jena/dist/KEYS >>> ** NB signing key has changed. >>> >>> >>> Git commit (browser URL): >>> https://git-wip-us.apache.org/repos/asf/jena/commit/f7b3c416 >>> >>> Git Commit Hash: >>> f7b3c416328bba4b8044e4ea8ad80e09ac51d720 >>> >>> Git Commit Tag: >>> jena-3.1.1-rc2 >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] 0 Don't care >>> [ ] -1 Don't release, because ... >>> >>> This vote will be open to at least >>> >>> Monday, 7 Nov 2016, 23:59 UTC >>> >>> If you expect to check the release but the 72 hour limit does not work >>> for you, please email within the schedule above with an expected time >>> and we can extend the vote period. >>> >>> Thanks, >>> >>> Andy >>> >>> Checking needed: >>> >>> + does everything work on Linux? >>> + does everything work on MS Windows? >>> + does everything work on OS X? >>> + are the GPG signatures fine? >>> + are the checksums correct? >>> + is there a source archive? >>> + can the source archive really be built? >>> + is there a correct LICENSE and NOTICE file in each artifact >>> (both source and binary artifacts)? >>> + does the NOTICE file contain all necessary attributions? >>> + have any licenses of dependencies changed due to upgrades? >>> if so have LICENSE and NOTICE been upgraded appropriately? >>> + does the tag/commit in the SCM contain reproducible sources? >> >> >> >> -- >> Stian Soiland-Reyes >> http://orcid.org/0000-0001-9842-9718 > > > > -- > Stian Soiland-Reyes > http://orcid.org/0000-0001-9842-9718 -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718
