Hi David, I was surprised seeing this error, so I did some investigation. It turned out that this is caused by a misbehaving Maven plugin - the one that is used to generate the dependencies.properties file which is later used by Pax Exam. This plugin sometimes puts resolved snashot versions (i.e. 0.2-incubating-20100717.020505-16) instead of the base versions (i.e. 0.2-incubating-SNAPSHOT) into the generated file. I'm not sure why it is observable only from time to time, but it's definitely a bug.
The plugin that is used there is SMX depends-maven-plugin. I found this SMX revision: http://svn.apache.org/viewvc?view=revision&revision=770436 Guillaume has already fixed this issue and the fix is available in the latest version of depends-maven-plugin. The only change that needs to be applied to SPI-Fly project is an upgrade in version of the depends-maven-plugin in the spi-fly-itests pom.xml. <groupId>org.apache.servicemix.tooling</groupId> <artifactId>depends-maven-plugin</artifactId> <version>1.1</version> needs to be changed to: <groupId>org.apache.servicemix.tooling</groupId> <artifactId>depends-maven-plugin</artifactId> <version>1.2</version> Do you want me to send you an updated patch? After this small modification is applied, spi-fly-itests should work fine. One more thing: This is a more general issue. I wanted to make the spi-fly-itests Maven and Pax Exam config look as similar to config in other Aries projects. I copied this configuration from application itests. I've just taken a look at other projects and can see that application, jmx, jpa, transaction, and web itest projects all use org.apache.servicemix.tooling in version 1.1. I'll create a new JIRA and attach a patch that upgrades version to 1.2 later today. Thanks, Bartek 2010/7/19 David Bosschaert <[email protected]>: > Hi Bartek, > > Looks good, however the tests fail for me. It comes down to a > dependency that PaxExam is looking for but can't find exactly in my > .m2 repo [1]. > Looking in my .m2\repository\org\apache\aries\org.apache.aries.util I > see the following versions: > 0.1-incubating > 0.1-incubating-20100329 > 0.2-incubating-SNAPSHOT > Also locally building util didn't help... > > Best regards, > > David > > [1] > ------------------------------------------------------------------------------- > Test set: org.apache.aries.spifly.SPIBundleTrackerCustomizerTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.777 > sec <<< FAILURE! > testProvidersWithandWithoutSpiHeader > [equinox/3.5.0](org.apache.aries.spifly.SPIBundleTrackerCustomizerTest) > Time elapsed: 0.75 sec <<< ERROR! > java.lang.RuntimeException: URL > [mvn:org.apache.aries/org.apache.aries.util/0.2-incubating-20100717.020505-16] > could not be resolved. > at > org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) > at java.net.URL.openStream(URL.java:1010) > at > org.ops4j.pax.runner.platform.internal.StreamUtils.streamCopy(StreamUtils.java:112) > at > org.ops4j.pax.runner.platform.internal.PlatformImpl.download(PlatformImpl.java:631) > at > org.ops4j.pax.runner.platform.internal.PlatformImpl.downloadBundles(PlatformImpl.java:407) > at > org.ops4j.pax.runner.platform.internal.PlatformImpl.start(PlatformImpl.java:186) > at org.ops4j.pax.runner.Run.startPlatform(Run.java:671) > at org.ops4j.pax.runner.Run.start(Run.java:220) > at org.ops4j.pax.runner.Run.start(Run.java:176) > at > org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:264) > at > org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142) > at > org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105) > at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86) > at > org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60) > at > org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84) > at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49) > at > org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246) > at > org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196) > at > org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186) > at > org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34) > at > org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44) > at > org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165) > at org.apache.maven.surefire.Surefire.run(Surefire.java:107) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005) > > On 16 July 2010 18:04, Bartosz Kowalewski <[email protected]> > wrote: >> Hi David, >> >> Thanks for applying the patch. Here goes another one... :) >> I've just created ARIES-363. This JIRA introduces an itests >> subproject. It also contains a Pax Exam test that checks if the >> existing SPI-Fly mechanisms work okay. >> >> Thanks, >> Bartek >> >> 2010/7/16 David Bosschaert <[email protected]>: >>> Hi Bartek, >>> >>> I have applied your changes in ARIES-353. >>> >>> Many thanks, >>> >>> David >>> >>> On 15 July 2010 16:59, David Bosschaert <[email protected]> wrote: >>>> Hi Bartosz, >>>> >>>> No I didn't have time to look at ARIES-353 yet. Will do so soon :) >>>> >>>> Cheers, >>>> >>>> David >>>> >>>> On 14 July 2010 09:17, Bartosz Kowalewski <[email protected]> >>>> wrote: >>>>> David, >>>>> >>>>> Have you had chance to take a look at the changes mentioned in ARIES-353? >>>>> >>>>> I can rename the main SPI-Fly project to something else than >>>>> spi-fly-core/org.apache.aries.spifly.core and send updated pom.xml >>>>> files if you like :). >>>>> >>>>> Thanks, >>>>> Bartek >>>>> >>>>> 2010/7/8 Bartosz Kowalewski <[email protected]>: >>>>>> Hi David, >>>>>> >>>>>> I've just created ARIES-353. It covers initial changes to be applied >>>>>> to to the SPI-Fly project structure. These changes transform SPI-Fly >>>>>> into a multi-module project. Once these changes are in SVN, I'll start >>>>>> contributing itests and other improvements. >>>>>> >>>>>> Thanks, >>>>>> Bartek >>>>>> >>>>>> 2010/6/29 David Bosschaert <[email protected]>: >>>>>>> Hi Bartek, >>>>>>> >>>>>>> On 25 June 2010 22:32, Bartosz Kowalewski >>>>>>> <[email protected]> wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I managed to make Eclipse Aspects/Weaving work inside a Pax Exam test. >>>>>>>> I can contribute this simple project with integration tests (of course >>>>>>>> after applying some clean-up) if you find it useful. I think that >>>>>>>> SPI-Fly requires a change in project structure anyway - it needs a >>>>>>>> parent project and a second subproject - spifly-itests. >>>>>>> >>>>>>> That would be greatly appreciated! >>>>>>> >>>>>>>> Some more comments on the SPI-Fly + AOP topic: >>>>>>>> 1. My understanding is that there's no single uniform mechanism for >>>>>>>> supporting AspectJ load-time weaving that would work in all OSGi >>>>>>>> containers. Due to the specifics of the OSGi world, container-specific >>>>>>>> mechanism are required. Am I right? For Equinox it's Equinox >>>>>>>> Aspects/Weaving and there's no such mechanism for Felix. This seems to >>>>>>>> be a really important disadvantage of using LTW in SPI-Fly. >>>>>>> >>>>>>> Yes - there is currently no general mechanism to support load-time >>>>>>> weaving in OSGi but this is something being worked on in the OSGi >>>>>>> Alliance so I expect that it will be possible in a standardized way in >>>>>>> the future. >>>>>>> >>>>>>>> 2. The problem with adding aspects to bundles is still unresolved. I'm >>>>>>>> not sure if there's a clean solution for adding aspects to consumer >>>>>>>> bundles (or bundles that provide the API). Of course some ugly >>>>>>>> solutions can be applied (like my original headache causing fragment >>>>>>>> based one), but these are more intrusive that we might wish. >>>>>>> >>>>>>> Yes, this is still an open question. Maybe something for the AspectJ >>>>>>> mailing list. I will post there. >>>>>>> >>>>>>>> 3. I started implementing support for SPI-Consumer and SPI-Provider >>>>>>>> headers that contain some data helpful whne running the aspect, i.e. >>>>>>>> api name and provider name/version for the Provider header, and some >>>>>>>> mechanism to define consumer constraints/hints in the SPI-Consumer >>>>>>>> header that would help the aspect that will tweak the thread context >>>>>>>> classloader to make decisions about providers. These mechanisms are >>>>>>>> similar to the ones that you described in one of your e-mails. >>>>>>>> However, I feel that we should first solve #1 and #2 above and only >>>>>>>> then it makes sense to continue with the implementation. >>>>>>> >>>>>>> cool stuff - looking forward to your contributions :) >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> David >>>>>>> >>>>>> >>>>> >>>> >>> >> >
