[otj-users] Announcing the launch of the OTDTBootstrap sub-project

[Stephan Herrmann]

We did it!
;-)

Eclipse plugins can be adapted using ObjectTeams/Java!

Those who have access to the FIRST-CVS will find a new project
OTDTBootstrap. (Those without such access may request either
a zip-file by email (ask me) or an account for the FIRST-CVS
(ask Jan or Carsten?)).

What's in that project:

Stage 1:
--------
You'll find a tiny class OTClipse and a bunch of configuration files 
that allow you to launch Eclipse from the commandline as an OT/J application.
The real cool thing here is the use of Java5 (no more use of JMangler
for this sub-project!). You should note that this version of the runtime
environment still has a few limitations (35 FAILs in our test suite,
as opposed to 16 FAILs using the old technology - but 97% success is 
already very good!).
For running OTClipse you will have to adjust several settings in the
project's classpath and the file run.sh (See file INSTALL.txt).
Windows users will have to convert the run-script to something their 
machine understands ...

Stage 2:
--------
OTClipse will - before invoking the regular eclipse startup - install
a team called StartupMonitor, which intercepts the initialization of
all plugins to be loaded. Right at that moment when the plugin has already
initialized its specific class loader, but before the plugin's main class 
is loaded, a lookup is made, whether a team class has been registered for
this plugin (currently this registry is hard-coded in StartupMonitor).
If a team is found the plugin's classpath is extended and the team is
loaded, instantiated and activated. Loading the team uses the plugin's
classloader, which ensures that the team can indeed adapt all classes in
this plugin (each team can only adapt classes of one plugin).

State 3:
--------
A tiny example Logger.java team demonstrates how any team installed in
Stage 2 can indeed hook into existing plugin behaviour without even
unwrapping the plugin's jar-file. This specific example simply logs
all invocations of MethodDeclaration.resolveStatements() within the
compiler to System.err.

I think this is real cool stuff!

cheers
Stephan