We discussed at the conf call to get a 3.0.0.alpha out as soon as possible, hence I moved almost all issues to be fix-for 3.0.0.beta and we only have a few left in 3.alpha (mostly build related).
The 3.0.0.alpha is mostly to get all our new stuff out in the hands of cutting edge users (besides nightlybuilds) and to get something based on Ganymede out too so we can community feedback.
The alpha version is not meant to be perfect but it should also not have big showstopping issues like VPE not working (https://jira.jboss.org/jira/browse/JBIDE-2010?focusedCommentId=12421854#a...) and Seam wizard not completing (fixed by Alexey yesterday).
If anyone knows of any such issues we need fixing before doing a 3.0.0.alpha please adjust their fix version to 3.0.0.alpha if they aren't already or create new issues for the issue so we can get them weeded out.
The goal is to get it build for friday next week.
See the full suggested schedule here https://jira.jboss.org/jira/browse/JBIDE?report=com.atlassian.jira.plugin...
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:
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.
Couple of suggestions: one of the most likely file filters people might
create for servers is for conf/jboss-log4j.xml, so that they can change
logging...etc. So, couple of suggestions here:
1.- The default root directory of a new file filter should be the server
root folder and not the deploy folder:
2.- Ability to define default "File Filters" for new Servers with
*-log4j.xml as example.
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
I assume you already know this but just to be clear:
JBoss Tools cannot bind itself to only support our platforms, the community version needs
to be available/supported too.
> The only versions you need to concern yourself with are the ones in
> the SOA Platform: JBossESB 4.2.1GA and (eventually) JBossESB 4.4. The
> current community release, JBossESB 4.3, will be close to 4.4 if you
> want to see something now, before the end of July codefreeze.
> On 1 Jul 2008, at 06:25, Denny Xu wrote:
>> Hi all
>> So far, JBossESB <http://wiki.jboss.org/wiki/JBossESB> has many
>> versions, are there any difference between the configuration files
>> and package structure of these versions(JBossESB 4.x)? and will we
>> support all of JBossESB <http://wiki.jboss.org/wiki/JBossESB> 4.x
>> and 5.x of future release or just support a specific JBossESB <http://wiki.jboss.org/wiki/JBossESB
>> > version?
>> Soa-tools-list mailing list
> Mark Little
> JBoss, a Division of Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt
> Parsons (USA) and Brendan Lane (Ireland).
> Soa-tools-list mailing list
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/