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