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 >>>>> >>>> >>> >> >
