[jbosstools-dev] Some thoughts and questions about the esp project wizard

[Rob Stryker]

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#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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev