maven version: 3.0.3 (I guess I could upgrade to 3.0.4, which seems to be
the latest)
The IBM JRE can be detected like this:
private boolean isIBMJRE() {
String vmName = System.getProperty("java.vm.name");
return vmName != null && vmName.equals("IBM J9 VM");
}
From:
Andy Seaborne <[email protected]>
To:
[email protected]
Date:
10/10/2012 08:52 AM
Subject:
Re: running dev tests
On 09/10/12 22:16, Simon Helsen wrote:
> ok, so I am running on Windows 7/64 bit and In my toplevel JENA
directory,
> I ran
maven version?
We are using the same version of the assembly plug in - 2.2.1
>
> mvn clean
> svn update
> mvn install package
(minor)
"mvn clean test" is enough to run the tests
> in ARQ, I ran into 2 issues during the ARQ tests, (see below), but I
> believe that is specific to IBM's JDK (both 6 and 7). So, I tried
> rerunning with Oracle's JDK 7 and then I run into the issue mentioned by
> Andy (i.e. tdb.TS_TDBLoader3). Now, when I run
>
> mvn install package -DskipTests=true
>
> I am hitting an issue building Fuseki (although the jars are created).
> This is what Maven spits out:
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.
> 2.1:single (create-server-assembly) on project jena-fuseki: Execution
> create-ser
> ver-assembly of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.2.1:single
> failed: Unexpected internal error near index 3
> [ERROR] .*\
> [ERROR] ^
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e swit
> ch.
Ug. Looks like a maven-ism. And Java is portable? Hmm.
Presumably the zip and/or tar.gz is not built. Assembly happens after
the jar artifacts are built.
> [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 rea
> d the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutio
> nException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
>
> [ERROR] mvn <goals> -rf :jena-fuseki
>
> Not sure where to find more information. I don't understand the message.
Nor do I - good(ish) news it builds somewhere.
> Finally, this is what I get for ARQ tests when running with an IBM JDK
7:
>
>
-------------------------------------------------------------------------------
> Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
>
-------------------------------------------------------------------------------
> Tests run: 1023, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.679
> sec <<< FAILURE!
> nv_add_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
> 0.005 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
> Source)
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
> at
>
com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.additionNV(NodeValueOps.java:125)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:124)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:116)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_add_22(TestNodeValueOps.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
This is IBM JDK specific (I think you've reported it before)
http://mail-archives.apache.org/mod_mbox/jena-dev/201206.mbox/%3C4FD7216A.3070008%40apache.org%3E
The test is
'P1Y'^^xsd:yearMonthDuration + 'PT4H'^^xsd:dayTimeDuration
which is not covered by the XSD specs (they do not define
yearMonthDuration + dayTimeDuration).
However, the javadoc for the operation does not forbid it and the
examples for Duration.add(Duration) suggest it is possible because Java
does not have separate types for the subtypes of duration.
The javadoc "spec" does allow IllegalStateException to be thrown.
NullPointerException does not count!
It could be coded around. I'd rather not remove the test because it's
not impossible in user data albeit a bit odd.
How can the code tell if it is running on an IBM JDK?
Andy