Re: [equinox-dev] Generalized OSGi transformations

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Kimberly,

While the Aspects project could be viewed
as a "transformer" this is really an implementation detail: AspectJ
developers should be expressing themselves in Java/AspectJ completely independently
of the deployment platform. Also the project's primary purpose is to exploit
rather than affect OSGi meta-data apart from the implementation of the
co-opt model which essentially adds entries to the Require-Bundle header
in the manifest for target bundles. In short users of the Aspects project
should not really be aware of what is going on at a low level.

>I've  
>been looking at the Aspect code a lot for inspiration and I think  
>that the current Aspect code could be migrated to a generalized  
>solution pretty easily.
Could you elaborate a little? The only
reason I use framework hooks is to intercept class loading and definition.
This allows me to call AspectJ in pretty much the same way that our JVMTI
agent does but without the need for Java 5. It also allows the possibility
of implementing some sophisticated and transparent byte-code caching to
improve performance. Are you thinking that the org.aspectj.osgi extension
could be implemented as a general purpose transformer?

Reading the Wiki has given me an idea
of how I might implement co-opt support without having to change the Equinox
resolver so this has been useful.

Cheers

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal) 
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

Kimberly Horne <kim@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

14/11/2006 21:02

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	[equinox-dev] Generalized OSGi transformations

I've begun to outline a possible generalized OSGi
transformation  
solution at http://wiki.eclipse.org/index.php/Product_Customization.  
It's a bit skeletal at the moment but should be much more readable in  
the next day or so.  I'd be interested in input from any interested
 
parties, particularly those developing the Aspect J service.  I've
 
been looking at the Aspect code a lot for inspiration and I think  
that the current Aspect code could be migrated to a generalized  
solution pretty easily.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev