very well done, I didn't even think to use that one that was mirrored to our svn repo! kudos!
Apologize but I cannot reproduce the issue, I didn't notice it neither on Jenkins (I forced a new deploy and went well) Which mvn command you execute? As a side note: can you run please `mvn --version`? This is mine: $ mvn --version Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /Applications/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.7.3", arch: "x86_64", family: "mac" Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Mar 8, 2012 at 2:57 PM, Lewis John Mcgibbney <[email protected]> wrote: > Changed the repo-ext in parent pom.xml to > > <repositories> > <repository> > <id>any23-repository-external</id> > - <url>http://any23.googlecode.com/svn/repo-ext</url> > + <url>http://svn.apache.org/repos/asf/incubator/any23/repo-ext/</url> > </repository> > <!-- Specific repository for Aduna / Sesame related dependencies. --> > <repository> > > And this seems to be working OK. > > I'm getting a problem with the basic crawler test suite here though, this > is also still reflected within the Jenkins builds > > My local surefire output > > ------------------------------------------------------------------------------- > Test set: org.apache.any23.cli.CrawlerTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.788 sec > <<< FAILURE! > testCLI(org.apache.any23.cli.CrawlerTest) Time elapsed: 10.265 sec <<< > FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at org.apache.any23.cli.CrawlerTest.testCLI(CrawlerTest.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > 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:300) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > > On Thu, Mar 8, 2012 at 10:42 AM, Lewis John Mcgibbney < > [email protected]> wrote: > >> Hi Again, >> >> After sending I thought I would read through my comments again... I think >> I need to clarify here. >> >> >> On Thu, Mar 8, 2012 at 10:29 AM, Lewis John Mcgibbney < >> [email protected]> wrote: >> >>> I simply don't know enough about it. There was (and is) a rather >>> interesting thread going on elsewhere just now regarding namespaces... >>> maybe we could rename packages to our own namespace and ship with them >>> until we can refactor these libraries out for the next incubating release, >>> or alternatively wait until they are available elsewhere e.g. >>> respotitory.apache.org or maven central repos? >>> >>>> >>>> By 'renaming the packages' I refer solely to ASLv2.0 licensed e.g. >> >> From Any23googlecode repos >> - org.apache.commons.commons-csv rename to >> org.apache.any23.commons.commons-csv >> >> -net.xeoh.jspf appears to be BSD licensed so we obviously can't muck >> around with namespaces and pacxkages here. Apache James seems to have some >> kind of jspf implementation though. [1] >> >> I've just noticed halfway though writing this email that we actually >> maintain our own svn repo-ext with both of the above libraries included. >> Can we not simply change the dependency resolution to point to this repos? >> >> [1] http://search.maven.org/#search|ga|1|jspf >> > > > > -- > *Lewis*
