This page last changed on Jul 10, 2006 by rossmason.

The following describe the plugins available, in development or planned.

Core plugins (Done)

Mule project nature, DTD based Mule Configuration verifier and preference page for specifying Mule installation.
This is provided in org.mule.ide.core (nature, DTD and builder) and org.mule.ide.ui (property sheet and preference page)
The DTD based Mule Configuration verifier currently checks the XML well-formedness and validation, and checks that all class files mentiones in className attributes actually exist in the project (whether imported onto the classpath or as actual classes).

Launch plugins - Launching a MuleServer with a selected configuration set (Done)

Support for launching Mule configurations. This based on the JTD launch (will use the Java nature if it has it) so that you compile your classes (for routers and endpoints) and execute them under Mule control, but also using the Eclipse debugger if you choose.
Right now, all of the jar files setup found in the Mule directory are added to the classpath. This should change with the advent of some kind of metadata for the supplied connecters, e.g. based on JBI.

Launch UI plugin: Tab-set for editing launch configuration. Right now, only one config file is supported per launch, this must change soon (order should also be specified, as it matters to MuleServer)

The plugins are called: org.mule.ide.launch and org.mule.ide.launch.ui.

Mule model plugin (Done, but needs extension to support graphical editor)

The model plugin is a "logical" model of Mule objects (endpoints, routers, transformers, etc.) and how they relate. It uses the Mule XML configuration files as a backing store. It should be possible to map several Mule XML configuration files into one model (and use the same resolution of duplicate names as is found in the MuleServer).
Support for modifying Mule configuration files, using an XMLBeans (or similar) mapping onto the XML configuration file(s).
I've tried using EMF (using the XML Schema mapping) but there is no free lunch there either, since the standard EMF model is geared towards the XML structure, not the logical model. Perhaps Eclipse's Web Tools Project has done this in a clever way.

It is IMHO crucial to use the XML files as carefully as possible, as to not make them illegible. This is where SSE has an advantage since it exposes both a DOM and a text editing interface, doesn't throw away comments, etc.

BTW: Mule uses a DTD, but XMLBeans uses Schema, so special loading/saving code is required.

Mule Project Wizard (Done)

The Mule project wizard will preconfigure a project for you with a Mule distribution and allow you to configure your src trees and custom libraries.

Custom Transport Wizard (Not Started)

This will create a template project with full annotation for writing a custom transport provider.

Model editor plugin (In progress)

To start with, this requires mapping the model (described above) into some kind of hierarcical editor (EditParts in Eclipse lingo), perhaps exposing structure and properties to the outline (TreeEditor) and properties view (IPropertyDescriptor).

If we make it clever, we'll have a two tab-viewer, one with the actual XML, and one with the structure.this?

Typing into the XML editor should entail the creation of new nodes in the structure and vice versa. This may not be as bad as is sounds, since the model needs to adjust to changes in the XML anyway (in the case of several configuration).

In fact, this is what WTP SSE supplied. Is it too "heavyweight" to require WTP for Mude IDE?

A "New..."-wizard is done already (sets up an empty configuration file with a model, or lets the user create from a list of samlpe config files)

Message level debugging (Not started)

This would entail writing an interceptor (or using server events) that may be used to stop and restart flows, and expose the message contents to the debugger.
Also, breakpoints can be defined and refined, typically in entry to and exit from a node. This could be coupled with the filter stuff.

Graphical configuration flow editor (In Progress)

It would be really cool, and not too difficult, actually, to integrate the model (and editor) with a GEF based editor. GMF is now a viable option and shows great promise in the Callisto timeframe.
The easy part is to hook up figures and editors for the elements in the EMF model, if using an unchanges EMF model. However, we might have to
The hardest part is to provide the meta information about number of inputs and outputs on routers, error handling strategies and (if supportable) message type compatibility between nodes (can this be determined statically, anyway?)

The goal is to be able to present the configuration in a cleaner way than the XML can, but in a way that preserves the XML underneath. And integrates well with both statistics and debugging.

Test harness (Not started)

A really cool feature would be to provide a test harness around a configuration to that a flow developer can specify expected inputs and outputs to a message flow. This would require a special editor and launcher.

Provider editors (Not started)

To make the configuration editing useful, provider specific property pages should be developed (via some kind of extension point) so that e.g. a file provider has a File Chooser, an MQ input provider lets the user select the queue from a list, etc.

These provider editors should also describe the run-time environment of the providers so we don't have to supply every jar known to Mule and the kitchen sink just to run the Hello sample.

I see two levels of extension, one which specifies just run-time JARs, and names of fields, etc. and another which requires custom UI elements (like support for snapping into known containers, JNDI tree browsing, DB viewing, etc.) Using the name of the required JARs, we can verify that the user has all the required JARs in place during validation.

Specific transformation subeditors (Not started)

Since transformation can potentially happen in several different languages, we could support "good" editor support for possible languages, like filter conditions, Groovy, BPEL, XSLT (is this supported at present?)

These should plug-in via some UI-oriented extension point.

Suggestion: Export wizard (Not started)

Export a Mule project to a JBoss RAR or similar Geronimo archive.

Export documentation using the config grapher or perhaps a text/HTML based report.

Document generated by Confluence on Oct 03, 2006 09:23