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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

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

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