Hi Bartek, That fixed it. I've applied the patch to trunk.
Best regards, David On 19 July 2010 15:17, Bartosz Kowalewski <[email protected]> wrote: > 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
