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