Hi Dave,
thanks (it helps).
If there are tests failing on Windows 7, it's bad (and good at
the same time that the test suite is signaling the problem).
Just to double check there are no changes in TxTDB trunk that
I do not have on my local copy, I've just did:
cd /tmp/txtdb/
svn up
At revision 1170728.
mvn clean test
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building TxTDB
[INFO] task-segment: [clean, test]
[INFO] ------------------------------------------------------------------------
[...]
Tests run: 697, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 13 seconds
[INFO] Finished at: Wed Sep 14 18:36:44 BST 2011
[INFO] Final Memory: 42M/296M
[INFO] ------------------------------------------------------------------------
There is obviously something bad going when we run TxTDB on
Windows 7. I am afraid I cannot be more helpful on this. :-(
@Andy, do you have a Windows 7 machine to investigate the
problem that Simon and Dave are experiencing?
Paolo
Dave Reynolds wrote:
On Wed, 2011-09-14 at 16:38 +0100, Paolo Castagna wrote:
Hi Simon,
indeed, very strange.
I do not have a Windows 7 machine to try, but if you have a Linux machine
you could try there, it would be really interesting to know the result.
Could it be something related to your Maven cache and somehow you still have
an old ARQ SNAPSHOT? You could try to manually delete the ARQ artifacts from
your Maven cache (usually in ~/.m2/repository/com/hp/hpl/jena/arq)
This is how you or others could run the test on different environments:
cd /tmp/
svn co http://svn.apache.org/repos/asf/incubator/jena/Experimental/TxTDB/trunk/
txtdb
cd /tmp/txtdb/
wget
https://issues.apache.org/jira/secure/attachment/12494332/TestTransSystem4.patch
patch -p0 < TestTransSystem4.patch
mvn package
mvn exec:java -Dexec.classpathScope="test"
-Dexec.mainClass="com.hp.hpl.jena.tdb.transaction.TestTransSystem"
(you need to adapt things to Windows)
FWIW I get errors trying that sequence on Windows.
Environment:
Windows 7 64 bit
Java 1.6.0_26-b03
START (disk, 100 iterations)
000: ..java.lang.UnsupportedOperationException: Quad: predicate cannot
be null
at com.hp.hpl.jena.sparql.core.Quad.<init>(Quad.java:49)
at com.hp.hpl.jena.tdb.lib.TupleLib.quad(TupleLib.java:127)
at com.hp.hpl.jena.tdb.lib.TupleLib.quad(TupleLib.java:118)
at com.hp.hpl.jena.tdb.lib.TupleLib.access$100(TupleLib.java:32)
at com.hp.hpl.jena.tdb.lib.TupleLib$4.convert(TupleLib.java:76)
at com.hp.hpl.jena.tdb.lib.TupleLib$4.convert(TupleLib.java:72)
at org.openjena.atlas.iterator.Iter$4.next(Iter.java:268)
at com.hp.hpl.jena.tdb.store.GraphTDBBase
$ProjectQuadsToTriples.next(GraphTDBBase.java:183)
at com.hp.hpl.jena.tdb.store.GraphTDBBase
$ProjectQuadsToTriples.next(GraphTDBBase.java:171)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:68)
at
com.hp.hpl.jena.util.iterator.Map1Iterator.next(Map1Iterator.java:35)
at
com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:68)
at
com.hp.hpl.jena.rdf.model.impl.StmtIteratorImpl.next(StmtIteratorImpl.java:33)
at
com.hp.hpl.jena.rdf.model.impl.StmtIteratorImpl.next(StmtIteratorImpl.java:21)
at
com.hp.hpl.jena.tdb.transaction.TestTransSystem.readModel(TestTransSystem.java:446)
at com.hp.hpl.jena.tdb.transaction.TestTransSystem.access
$100(TestTransSystem.java:59)
at com.hp.hpl.jena.tdb.transaction.TestTransSystem
$Reader.call(TestTransSystem.java:163)
at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
However, I get some test errors during the build and had to force Maven
to ignore those in order to get a build, so this is not a clean run.
Surefire logs for the test-during-build errors are attached.
This is not my normal dev environment so there is little chance of stale
maven cache.
Dave