Equinox Aspects 1.0 M7 - New and Noteworthy

The major work that was done in the M7 milestone of Equinox Aspects focussed on more fine grained control of the weaving process. We discussed these enhancements a lot with the AJDT team and have now a first version of this available. Please give feedback on this improvement and tell us, what you observe.

General
Graduation We started the graduation process for graduating Equinox Aspects out of the incubator area into a general Equinox component.
Different weavers The general design of Equinox Aspects allows you to use your own bytecode modifiers instead of AspectJ's aspect weaving together with the base Equinox Aspects infrastructure. To prove this we implemented (as an example) a weaving service that connects Equinox Aspects to the spring dynamic modules infrastructure to make all the spring load-time weavers (AspectJ, JPA, etc.) work within OSGi using Equinox Aspects.
You can find more on this implementation in this blog entry:
Load-Time Weaving for Spring-DM

Weaving
Manifest-only fine-grained aspect weaving control We implemented a number of additional options and mechanisms that allow you to control the weaving of aspects on a more fine-grained level. The major discussion of this took place in bug 255682.

What is new?

  • the packages of aspects in aop.xml needs to be exported via the bundle manifest. If they are not, the aspect is no longer woven into other bundles.
  • you don't need an aop.xml file anymore. Instead of list your aspects within this special file, you can add them as attribute to your export-package declaration in the manifest:
    Export-Package: com.foo.bar;aspects="Tracing,Monitoring"
  • if you export an aspect, you can define a policy when this aspect should be woven into bundles that are depending on this package (via Import-Package or Require-Bundle):
    Export-Package: com.foo.bar;aspect-policy:=opt-out;aspects="Tracing,Monitoring"
    In this "opt-out" case your aspects are woven into dependend bundles unless they explicitly prevent those aspects from being woven into them.
    If you use "opt-in" instead, these aspects are NOT woven unless the dependend bundle explicitly asks for them being woven.
  • if you import a package (or require a bundle) that exports an aspect, you can define an "apply-aspects" directive to tell Equinox Aspects whether to weave the imported aspects into your bundle or not.
    Import-Package: com.foo.bar;apply-aspects:=true
    This means the aspects that are exported from the bundle that satisfies this import should be woven into your bundle. If you define "false", then those aspects are not woven into your bundle.
More details on this can be found in the comments for bug #255682, especially in comment #18 and following.

The supplementer mechanism is not touched by this. If you define aspects within a bundle via aop.xml or the manifest, export the package and supplement another bundle, those aspects are being woven into the supplemented bundle as always.

The new mechanism should be completely backwards compatible. So if you run your aspect bundles as they are with the new build and observe any problems, please open a new issue in bugzilla.
Declare bundles as finised Equinox Aspects tries to avoid weaving a bundle whereas possible to avoid the weaving overhead. But there are situations where Equinox Aspects cannot decide on its own efficiently whether to weave a bundle or not. This is the case for bundles that contain @Aspect-style aspects, define them in aop.xml or via the manifest and where not compiled with AJDT (or AspectJ in general). In those situations Equinox Aspects needs to weave the bundle to "finish" the aspects in bytecode.
Because Equinox Aspects cannot easily decide whether the aspects inside a bundle are finished or not, it always weaves the bundle with its own aspects in such cases. If you know that you compiled your aspect bundle with AJDT and therefore know that your aspects are finished, you can tell Equinox Aspects this in the manifest. Simply add:

Eclipse-AspectBundle: finished
Aspects in fragments We fixed a bug that prevented you from defining an aspect inside a fragment together with a supplement bundle definition. This works now.

Caching
Caching of generated classes In the past the caching service denied to cache generated classes for some reasons, especially the problem of invalidating those cache items. Since the latest versions of Equinox Aspects deal with the cache invalidation using the OSGi bundle names, versions and update dates, we are now able to cache generated classes the same way we cache all other woven bytecode. This is implemented in this milestone build for the standard caching service.
This was the last step towards getting zero-overhead startup performance for the cached scenario. :-)

The above features are just the ones that are new since the previous milestone build. Summaries for earlier 1.0 milestone builds: