Hi David, No problem. I'll refactor and send it again once I'm back. However, this will still be just a sandbox. While these changes were made against exisiting SPI-Fly projects, these are only initial modifications. As it is stated in ARIES-373, there are some problems that need to be resolved before these changes find their way to the Aries SVN repo.
Thanks, Bartek 2010/8/5 David Bosschaert <[email protected]>: > 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
