Hi David, Sorry for the late response. I was doing a clean-up in my workspace before leaving for vacation and I realized that I forgot to contribute my sandbox that proposes how to use aspects with SPI-Fly. I've just made a quick clean-up and created a patch. It was a really quick clean-up :). The code still requires refactoring. If you find any part of this patch useful, I can create a better one once I'm back from vacation.
The patch and some details are here: https://issues.apache.org/jira/browse/ARIES-373 Thanks, Bartek 2010/7/19 David Bosschaert <[email protected]>: > 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
