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