[news.eclipse.technology.equinox] Re: AspectJ-enabled runtime implementa

["dominic" <dominic@xxxxxxxxxx>]

Lemme just say that my imagination went crazy after this.

One typical problem i was trying to find a solution for was the integration
of different ui plugins. Mozilla does it via overlays. And Netbeans does it
via branded jar files. If  i am not mistaken there is no way in eclipse to
specify how ui artifacts coming from different plugins are integrated
together. This is a major problem when people are trying to use eclipse as a
platform for non ide applications. They usually end up hacking into the
eclipse code. I imagine menus,tbars, context menus (right
clicks),preferences to be cross-plugin pointcuts that could benefit greatly
from this idea.


"Martin Lippert" <lippert@xxxxxxx> wrote in message
news:b5vpjj$e04$1@xxxxxxxxxxxxxxxx
> Hi all,
>
> my name is Martin (Lippert) and I am new to this group. Brian Barry and
> Jeff (McAffer) told me that this might be the right place to talk about
> my ideas. So I hope you are interested in it, even if it might sounds a
> bit strange at first sight.
>
> During the last weeks and months I had the idea of bringing AspectJ and
> the Eclipse plugin model closer together by allowing people to develop
> applications using both, aspects written in AspectJ and plugins using
> the Eclipse runtime. They would be able to write aspects in AspectJ,
> compile them with their compiler (or the respective plugin for the Java
> Tooling inside Eclipse) and plug them into the system as a normal
> plugin. The main motivation is that people are interested in both:
> plugins as their base runtime infrastructure and aspects to modularize
> crosscutting concerns.
>
> I thought about load-time weaving to allow them to individually develop
> each plugin. Today, they can use an aspect only inside a single plugin,
> because the compiler weaves the aspect into the other classes. With
> load-time weaving the idea of Eclipse to encapsulate each plugin (even
> with aspects that define cross-plugin pointcuts) would become possible
> for aspects.
>
> So I implemented a modified version of the core plugins (boot and
> runtime) to realize this behavior and demonstrated it at the AOSD
> conference last week. The feedback was very positive and I would like to
> continue to improve the implementation and make it available to the
> people who are interested.
> The only thing that makes this a bit complicated is the fact that I had
> to implement a modified version of the base plugins. It was not possible
> to write a plugin that enhances the runtime in the way I want it to be.
>
> The main reasons for this:
> - I had to inject the weaving at class-loading time. The current class
> loader of Eclipse do not allow me to enhance their behavior for such
> kind of things.
> - I had to add dependencies between plugins at runtime (depending on
> which aspect got woven into which class).
> - I had to add some setup code that got called after the registry is
> initialized but before the application starts.
>
> And this is exactly the point where it might be interesting for this
> project. These are exactly the points where I would love to make the
> runtime more flexible. This might seem a bit strange (especially the
> load-time modifications of classes), but the load-time weaving of
> aspects opens a totally new world of possibilities for aspects and
> plugins used together.
>
> So I am highly interested in hearing your opinions on that. I can also
> provide more technical details of the possible enhancements to the
> runtime. I would also love to contribute some code for this kind of
> modifications, if possible. What do you think?
>
> Best regards,
> Martin Lippert
>
>
> ---
> Martin Lippert
> email: lippert@xxxxxxx
>
>