These are the extension points defined by the org.eclipse.stp.eid plugin.
Runtime Extension Point
For each runtime that supports EIPs, there is an extension:
<eipRuntime name="nnnn" version="x.y.z" id="reference"> <ns prefix="xxxx" uri="uri:asdf" /> * multiples </eipRuntime>
If someone defines two extensions with the same name and version, then the namespaces are *added* to the ones that are already registered. If the namespaces are duplicated, they are ignored. If the prefixes are duplicated, but the uris are different, the most recent prefix gets a number appended to it to prevent explosions.
Other extensions will use the id of the runtime to refer to it.
Coordinator Extension Point
A runtime can be associated with multiple coordinators - these guys are responsible for constructing the folder structure and the various resources needed before configuration starts. They kick off and coordinate the configuration too, and then they finalize the project, do cleanups etc.
The reason why this is a separate extension point is to allow variety in how you structure your projects for a runtime. So if you use maven for example you could have a CamelMavenCoordinator that sets up the project appropriately, or you could have a CamelAntCoordinator that sets it up for an ant build.
<eipCoordinator id="..." class="...ICoordinator..."> <runtime id="..." /> <runtime name="..." version="..."/> </eipCoordinator>
The action that comes down from the UI should have the runtime and the coordinator details in it. The runtime gets picked (somehow) and then the coordinator is set by the menu choice or thru preferences or something like that. Preferences might be a good place for defaults.
Component Extension Point
There's a whole slew of EIPs, and these are called components for now. People should be able to add their own, and extend the capabilities of the system. So we need an extension for EIPs too.
<eipComponent model="...resource..." -> the model file name="..." -> name of the component id="..." -> id for referring to this one largeIcon="..." -> largeIcon for the canvas smallIcon="..." -> small icon for the palette category="..." > -> category for the palette <description> All about this component </description> </eipComponent>
There's nothing here that says a particular component needs to be tied to a particular runtime, it's really just a model definition with some graphical bits and a name for human consumption. This takes the graphic stuff out of the existing model, which is a good idea.
Generator Extension Point
The piece that's missing is the bit which says "here's how you generate the configuration for this component when you are using this runtime with this particular version". This is the generator extension. Right now we are going to use JET2 and that's all there is to it.
<eipGenerator class="...IGenerator..."> <runtime name="..." version="..."> <component name="..." /> <component name="..." /> * </runtime> <runtime id="..."> <component name="..." /> <component id="..." /> * </runtime> </eipGenerator>
Proposed Extension Points
These ones are proposed. It's not decided yet whether or not it is a good idea to include them! Let us know via a bugzilla entry if you would like them to be put in place.
Repository Extension Point
There a fifth extension, and this is a bit speculative at the moment. There's this idea of a directory-based cache for the components, where everything is copied to and then they are parsed and loaded up. This serves a repository for new stuff that a user can put in too, so you can extend the component capabilities without having to create a plugin. I think that this capability is not fully baked in the current code, and while it's a nice idea, there's some work to put together a real strong implementation.
In any case, this is a candidate for this fifth extension - a way to share components between integration designer people.
<eipRepository provider="...IComponentRepository..." name="..." id="..."> <description>xxxx</description> </eipRepository>