[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.equinox] Re: AspectJ-enabled runtime implementation 
Hi,

My 2c go with Peter on this.  This sort of function (menus etc) should be
the subject of explicit, concrete API not runtime bytecode transforms based
on user code.

I agree.

I still like the idea of investigating aspects and plugins.  A new branch
may well make sense.  Questions:
- Do you feel comfortable working against a version for now while we sort
out the branching story?  Basically you can slurp a version (2.1) and
prototype examples on your own until you want to share your code.
Okay, sounds good. I plan to do two things:
1. integrate the bytecode transformation into the runtime via an additional extension point.
2. provide an AspectJ dynamic weaving plugin that provides an extension to this new extension point. This is my first use case for the additional flexibility of the runtime.

- Could you write a brief plan/statement describing this work area.  I'm
thinking of something similar to what we have for Dynamic Plugins.

Sure. Give me just a few days... ;-)

Best regards,
Martin




Jeff

"Martin Lippert" <lippert@xxxxxxx> wrote in message
news:b6s7dm$9bt$1@xxxxxxxxxxxxxxxx

Hi,


The dynamic weaving is a fantastic idea but I think we should be a bit
careful. Supporting it is fantastic, making it a centre of an
architecture would be 2 steps too far for me today. I think we need a
lot more experience with this before one can take such a drastic step.


Regarding the menues, toolbars, and context menues I am not quite sure,
too. But what do you think of a source branch to try out the dynamic
bytecode modification for the runtime? I would then add an AspectJ
plugin for that to let us (and others) experiment with these
possibilities. Then we can go a bit deeper into the discussion of
questions like:

- How could the Eclipse system itself benefit from aspects?
- What happens in the case of dynamic un/reloaded plugins that promotes
aspects?

Your opinions?

-Martin





Kind regards,

   Peter Kriens

dominic wrote:


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