STP/EID Component/EID Developers
I'm working on this bug to add (quickly) generation capabilities for Apache Camel. There will be a tutorial on it at EclipseCon 2008, that's why it's being done quickly :) As I go along, I'm taking some development notes for reproduction here.
EID extracts all the models from the org.eclipse.stp.eid/componentModel directory and puts them into a .cimero2 directory in your home.
Next, each component in the .cimero2 is opened, scanned, and there is an attempt to detect the ESB to which that component belongs to see if it is the same as the one that has been chosen at startup time.
If a component is offered by the chosen ESB, a component model gets created in memory including the name for the component, what ESB it belongs to, the icon for it and the component type. Then it's added to the list of component models, which gets reflected on the palette (see org.eclipse.stp.eid.Parser).
Because of the way this is done, you can add your very own component model definitions in this directory, and they will be available on the palette when the canvas starts up.
- The startup could be streamlined - unloading all of the component models to a directory and then going back again to the directory and rummaging through all of the files that are there is heavy. It would be better to load the component models directly from the plugin jar and only then look in the .cimero2 directory. With a planned structure in there, it would be possible to load all of the appropriate component models, without having to open all the XML files and parse them.
- What is really needed here is the concept of a supported components repository - the palette should ask for all of the component models that are available from the current ESB - that sounds like an extension point.
Once you have created the graph of connected component models, you are in a position to generate configuration. At the moment, it's not easy to see what properties are missing, etc. When you choose a generation option, it eventually all goes through a single choke point org.eclipse.stp.eid.generator.GeneratorImpl, which initially creates a directory structure, then kicks off specific JET templates to construct the various configuration elements in the appropriate places.
One thing here is that JET is set up to create the Java files at runtime and then Eclipse compiles them and uses them to generate the configuration. This has the advantage of allowing people to jump into the plugin and change the template, but it does slow things down and it means that it is very difficult to run this headless. Also, it's using an old version of JET, i.e. not JET2.
As of r1871, the EID has been updated to use JET2, and does not generate the Java template runner code at runtime. The templates are generated by a project builder during development and the code is checked in as part of the org.eclipse.stp.eid.internal.generation package in the org.eclipse.stp.eid.generator plugin.
- Do something to indicate that the picture is not yet ready for code generation - ideally this would be decorators on the GMF figures so that you would know exactly where things are incorrect or missing, but I don't know how to do that yet :)
- Consider having the capability to use a builder in the background - i.e. when you are creating an EIP graph (and it's in a valid state) then there is a generation going on all the time in the background every time there is a change. Then you don't have to bother yourself actually pressing a button to make it run.
Update the code generation to use JET2 and also consider not generating and compiling the Java at runtimeDone