*1. Project structure*
I think the project should be look like:
a. /src/ folder: Java source folder
by default yes, but should be user controllable.
b. /ESBContent/ folder: it will contain the following artifacts:
. META-INF Folder: the folder is used to contain jboss-esb.xml
the folder will be packaged to ESB deployement package
. lib folder: it is for containing the jars that needed
. classes folder: the project output folder
I don't recall binary results being available in the projects...this is only there
when deploying, correct?
. some other artifacets, such as /jbm-queue-service.xml
/so the structure looks like a Web project, but we should not create
ESB project based on the web project wizard,
since the ESB project has different structure and different format of the deployment
package, and it need a
unique Module type.
ok - but i guess it will still use the wtp web project setup.
*2. JBossESB facet:*
The JBossESB facet will be used to configure the project's ESB runtime and ESB
version control. The project
structure and some default artifacts will be created when a JBossESB facet with a
specified version is configured, so if there is a new
ESB version need to be supported, and the new ESB version has something different from
the already supported
ESB version , then we just need to extend the JBossESB facet and add a new facet install
class to handle it.
*3. Target ESB Server( maybe Target Messaging product?)*
Since there are two types of queue configuration files: jbm-queue-service.xml and
different messaging product. So the project should contain target esb server
Here is a topic in ESB forum:
Overall target runtime makes sense (just like for webapps/ears), but messaging product is
just something a facet should control.
*4. Integrate with current ESB editor
*For now, Jboss tools has a editor for jboss-esb.xml, we also can associate the file
with the editor
Not sure what this means ?
*5. Sample content(Template):*
Provide a extension point for it. the extension has the following
properties at least :
* esb version: the templates will be filtered by the version of the esb facet of
* description : when user select a template, on the wizard page, show
the description to the user.
* template: the template should be the main stuff of this extension
point, we should determine the format of the template, since it may contain some
code and other artifacts such as some ESB config files, so the template may be an
archive file such as a jar
file or some other sort of it.
* template install class: to handle some additional operations that template
All sounds good - but I'm interested in getting the above issues done first so we get
something usable for deployment upfront.