David, I've just updated ARIES-373 and attached a new veriosn of the patch.
Thanks, Bartek 2010/8/5 Bartosz Kowalewski <[email protected]>: > 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
