Hi Bartek, If you're planning to do more work on it I would probably prefer to wait until you've finished the patch.
Cheers, David On 5 August 2010 02:53, Bartosz Kowalewski <[email protected]> wrote: > 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
