I checked out the components separately. Note that this is currently
suggested in the documentation -
http://jena.apache.org/getting_involved/index.html -> perhaps it would be
good to document the single checkout as you suggest below.
Trying a single checkout I get the revision number 1349027. I run into the
same ARQ problem (attached log file again) at first. However, I checked
and I was using IBM's JRE 7 (*) - I also tried with IBM's JRE 6 and the
same effect. I then tried with Sun's JRE 7 (**) and things worked. That is
not good of course. I understand this is an experimental feature, so
perhaps it won't affect us, but it would be good to understand why there
is a difference here.
(Side question: when the single build fails because of a junit, it stops
the rest - is there a way to continue?)
I did see the issue with tdbloader before as well, but it didn't write
anything in the log file and I had wrongly assumed that it was only a
consequence of the problem with TS_Factory. I attached the console output
below. The log file is still empty
Simon
(*) java version "1.7.0"
Java(TM) SE Runtime Environment (build pwa6470-20110906_01)
IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 amd64-64 20110810_88604 (JIT
enabled,
AOT enabled)
J9VM - R26_Java726_GA_20110810_1208_B88592
JIT - r11_20110810_20466
GC - R26_Java726_GA_20110810_1208_B88592
J9CL - 20110810_88604)
JCL - 20110809_01 based on Oracle 7b147
(**) java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b22)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
Running tdb.TS_TDBLoader3
18:39:27 ERROR BPlusTreeRewriter :: **** Not the root: 1024
com.hp.hpl.jena.tdb.index.bplustree.BPTreeException
at
com.hp.hpl.jena.tdb.index.bplustree.BPlusTreeRewriter.packIntoBPlusTr
ee(BPlusTreeRewriter.java:89)
at
org.apache.jena.tdb.store.bulkloader3.NodeTableBuilder2.buildNodeTabl
eBPTreeIndex(NodeTableBuilder2.java:296)
at
org.apache.jena.tdb.store.bulkloader3.NodeTableBuilder2.close(NodeTab
leBuilder2.java:172)
at tdb.tdbloader3.exec(tdbloader3.java:216)
at arq.cmdline.CmdMain.mainMethod(CmdMain.java:101)
at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
at tdb.tdbloader3.main(tdbloader3.java:108)
at tdb.TestTDBLoader3.run(TestTDBLoader3.java:120)
at tdb.TestTDBLoader3.test(TestTDBLoader3.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
Method.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
lable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
thod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMet
hod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.
java:28)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
ner.java:69)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
ner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provide
r.java:236)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4
Provider.java:134)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider
.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke
(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(Provi
derFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Fork
edBooter.java:103)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:
74)
From:
Andy Seaborne <[email protected]>
To:
[email protected]
Date:
06/11/2012 05:23 PM
Subject:
Re: errors when running the tests?
(How can the svn version numbers be different?)
Building a single checkout of the jena/trunk, I do not see the ARQ test
failure. The other legitimate way to build is from the source-release
or from the tagged release tree.
svn co http://svn.apache.org/repos/asf/jena/trunk/ JENA
cd JENA
mvn clean install ##NB "install"
I do not get an ARQ failure. Looking at the test it's addition of
durations so (1) not critical (new feature) and (2) getting the XML
Datatype support to work was an experience anyway.
I used a java7 system: Sun Java 1.7.0 b147
What are you using?
I see a problem with tdbloader3 tests on windows, but not your report.
Your may be a failure to clean up and I've rejigged that bit.
Andy
PS I did see a failure in jena-core - but rerunning "mvn clean install"
and it went away. This is rather worrying.
> and I had noticed the same
> problem last Friday.
<!!!!!/>
On 11/06/12 21:29, Simon Helsen wrote:
> thanks Rob
>
> I did mvn clean package, But I tried with -U as well and it makes no
> difference
>
>
>
>
> From:
> Rob Vesse<[email protected]>
> To:
> "[email protected]"<[email protected]>
> Date:
> 06/11/2012 03:42 PM
> Subject:
> Re: errors when running the tests?
>
>
>
> Ok so revisions match up so we are talking the same code.
>
> I can't comment on the TDB errors not knowing that part of the codebase
> but the ARQ failures look to do with some XSD stuff which I know Andy
> worked on recently. Did you do a simple mvn clean package or did you do
a
> mvn clean package ?U to force updates of all dependencies. That is
> unlikely to magically fix things but occasionally it does.
>
> Interestingly when I fire up the Windows 7 VM and do this I see 1 test
> failure on ARQ related to a timeout not occurring which I'm not sure
what
> the culprit of is but not the two failures you see.
>
> For TDB I do see the same failures as you, as I said I can't help
diagnose
> those so will have to defer to Andy on that
>
> Rob
>
> From: Simon Helsen<[email protected]<mailto:[email protected]>>
> Reply-To: "[email protected]<mailto:[email protected]>"
> <[email protected]<mailto:[email protected]>>
> Date: Monday, June 11, 2012 11:35 AM
> To: "[email protected]<mailto:[email protected]>"
> <[email protected]<mailto:[email protected]>>
> Cc: "[email protected]<mailto:[email protected]>"
> <[email protected]<mailto:[email protected]>>
> Subject: Re: errors when running the tests?
>
> I picked up the revision this morning EST and I had noticed the same
> problem last Friday. The revision number on arq is 1348833 and on tdb it
> is 1348829
>
> I have attached the relevant error reports
>
> Simon
>
>
>
>
>
>
>
> From: Rob Vesse<[email protected]<mailto:[email protected]>>
> To: "[email protected]<mailto:[email protected]>"
> <[email protected]<mailto:[email protected]>>
> Date: 06/11/2012 02:10 PM
> Subject: Re: errors when running the tests?
>
> ________________________________
>
>
>
> I can't speak for other committers but I'm not seeing any test failures
> but then I like most of the other committers run on non-Windows
platforms
> (OS X in my case)
>
> Maven uses the surefire plugin to run unit tests and you can find
reports
> under target/surefire-reports for individual modules.
>
> I know Andy has made a ton of commits lately and there were some notes
in
> the log about enabling and re-enabling some failing tests during some of
> his development work around addressing the TDB issues. What revision
are
> you on precisely? Svn reports 1348948 for me. Is it possible you
picked
> up a revision that was during the time Andy was doing his work?
>
> Rob
>
>
>
> On 6/11/12 10:49 AM, "Simon Helsen"<[email protected]<
> mailto:[email protected]>> wrote:
>
>> Hi,
>>
>> When I update my Jena projects with svn and then run mvn clean package,
I
>> am seeing junit errors in ARQ and TDB. I am running this on Windows
7/64
>> bit. Does anyone else see this? It seems to me that it is questionable
to
>> release Jena if not all junits run through
>>
>> Is there a way to produce log files when I run the tests? That way I
can
>> easier share what I am seeing
>>
>> Simon
>
>
>
>
>
>
