On the note of the differing revision numbers svn info reports two revision numbers:
1 - Revision which is the overall revision for the repository 2 - Last Changed Rev which is the most recent revision which changed the current directory you are invoking the svn info command in/upon. So for example running svn info in my current working copy (which is a checkout of the trunk) but from within the jena-arq directory gives the following output: URL: https://[email protected]/repos/asf/jena/trunk/jena-arq Repository Root: https://[email protected]/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1348948 Node Kind: directory Schedule: normal Last Changed Author: andy Last Changed Rev: 1348833 Last Changed Date: 2012-06-11 06:22:34 -0700 (Mon, 11 Jun 2012) Rob On 6/11/12 3:43 PM, "Simon Helsen" <[email protected]> wrote: >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 >> >> >> >> >> >> > > >
