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

You cannot create a project with both the EAR facet and EJB facet. This model should be coppied when making the ESB facet. You do this by setting up conflicts / restrictions in the module type. I can help you locate how to do this when the time comes as I've done it before. If you have any problems at all locating the proper extension points for this task, or even just need to know where to begin looking, ping me. I will definitely help you on this task as I've done it before. - Rob Denny Xu wrote: > Rob Stryker wrote: >> 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. > I do not mean not to use project wizard, just mean installing the esb > facet will be one part of the project wizard, so something related to > versions will be done when installing the ESB facet. >> 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. > If these wizards could be reused , that would be fine. I want the > project should have only one module type, because the project have > more than one module type , it will have more than one package > packaged by different module factory when deploy it by WTP server, is > that right? > > Denny >> >> 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 >> >

I don't recall binary results being available in the projects...this is only there when deploying, correct?

> *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 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. > All sounds good - but I'm interested in getting the above issues done first so we get something usable for deployment upfront.

>>> *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 ? >> >> > you know, JBoss tools has a ESB tree editor, I mean that when the > project is created and the user want to edit the jboss-esb.xml config > file, we can > open the file using the ESB editor . > ...but that is already done by default, so no work needed ;) >>> *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. >>> >>> >> All sounds good - but I'm interested in getting the above issues done first so we get something usable for deployment upfront. >> >> > John suggested to quickly develop a prototype of the wizard at first, I > think it may be worked out next week and then start to code base on it. > ok, so you will be using the WTP wizard framework and module types?