I disagree with the idea of not using the project wizard. I am somewhat
familiar with those classes and I believe you can leverage a lot of them
effectively even for the project structure you've suggested.
As for requiring it's own module type, that also is not a problem. It is
one class that you must extend to turn projects into modules. I have
several examples of these classes in the AS tools that turn single files
into a module or project archives into modules. You can turn anything
into a deployable module (at least as far as wst.server is concerned).
In short, using large portions (and especially the base classes) for the
wtp / ejb / dynamic web / whatever project wizard could be beneficial.
These wizards contain a lot of utility methods for setting up projects
that use the flexible project model and I don't think you should ignore
that.
That's just my input, though =]
- Rob
Denny Xu wrote:
Hi John
Here is what I am thinking about the ESP project wizard and also some
questions.
*1. Project structure*
I think the project should be look like:
a. /src/ folder: Java source folder
b. /ESBContent/ folder: it will contain the following artifacts:
. META-INF Folder: the folder is used to contain jboss-esb.xml
and deployment.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
. 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.
*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 jbmq-queue-service.xml for different
messaging product. So the project should contain target esb server
information.
Here is a topic in ESB forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161447#...
Q: do we need to support the older product JBoss MQ or just need to
support Jboss server which use JBoss Messaging ?
*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
*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 the project.
* 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 source 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 providers want.
*6. Default Artifacts:* If users don't choose any template, some
default artifacts should be provided, such as
jboss-esb.xml, are there any else artifacts?
*7. Deployment:* it is also an import part. A module type and module
factory should be defined, so the project can
be packaged by our own way
Any comments are welcome.
Thanks
Denny
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev