Problem Statement
We need to provide wizards in Eclipse that create JBESB projects and supply sample content. The JBESB "Quick Starts" will be the primary content providers.
Background
A very similar model can be found in the Eclipse PDE tools . Try creating a number of plug-in projects, using the sample content choices (for example: views or editors). Also try adding sample content to an existing plug-in using the same wizard. Pay special attention to the wizard flow/lay out, and how platform versions are handled.
Design Considerations
Two Issues: Wizards and Sample Content
Broadly there are two issues involved: wizards for ESB artifact creation, and wizards for sample creation. Wizards for ESB artifact creation include, but are not limited to:
JBESB project: Creates an Eclipse project associated with JBESB. The structure of this project (for example: which folders are a created, where specific resources can/must be located) and the method of association (for example: an Eclipse nature or WTP facet) need to be determined. Currently JBESB tools has a simple wizard for this functionality.
JBESB configuration file: Creates a jboss-esb.xml file. Currently JBT has a wizard for this. Additional functionality (such as handling different versions of the jboss-esb.xml file) or addition content might be required.
Secondary configuration files: We might want to create, for example, queue binding files from jboss-esb.xml. Whether this should be created automatically by the jboss-esb.xml editor (not likely), through an explicit generate wizard (useful if these files might need to be tweaked), or as part of deployment package construction (if they are not relevant to developers) needs to be decided.
The second issue is the provision of sample content. Ideally we'd have something like the Eclipse PDE tools, where the various sample choices are given in a list (including descriptions) and associated configuration/classes can be renamed. We should be able to add sample content to new projects or to existing projects (like the PDE tooling allows, for example, creation of a sample view in a new plug-in project but also adding a sample view to an existing plug-in project. In the latter case, the wizard is launched through the PDE configuration editor: we need to find a suitable launch location (jboss-esb.xml file?).
Extensible Sample Content Provisioning
It is not realistic (nor advisable) to expect that one plug-in will host all the sample content. Rather, we should create an extension point where sample content can be contributed. This will allow the base plug-in to contain only the wizard components and framework (content contributions, templating, etc.) with extenders providing the actual content. It will also allow us to provide additional examples without full releases (just add new plug-ins to the existing set) and update released content. Finally, these contributions should be tied to a SOA-P run time version, to avoid creating sample content that is not valid on the user's target server.
Since SOA-P run time version numbers do not (necessarily) indicate backward/forward compatibility, we will adopt an open-ended versioning policy with a base version set. Thus, sample content will come with a minimum SOA-P run time version that it is known to work with, and will remain current from that minimum version up to, but not including, a later minimum version for the same sample content contribution. This will allow us to incrementally update samples as necessary to support SOA-P run time changes, while preserving working sample content across versions. The wizard should detect the SOA-P run time level set for a target project, or ask the user to choose. For flexibility, the wizard should also allow the user to choose different versions of the sample content, providing warnings that it is not certified for the target server (for example: an advanced user might want to tweak a previous example in a certain way, and we should not prevent this).
Versioning of Sample Content
The validity of sample content might be tied to specific SOA-P run time versions. Creating sample content that does not run on the user's SOA-P server is a very serious failure, and will severely detract from usability. Therefore, we need some way of identifying which version(s) of the SOA-P run time specific sample content is valid in. (See JBIDE-2399 for details of the general case.)
Question: So far, 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 4.x and 5.x of future release or just support a specific JBossESB version?
Answer: I think at a minimum we'd need to support the 4.x versions of JBossESB, though which exact x needs to be determined. A good place to ask this question would be on the SOA-DEV mailing list. After discussion on that list and an answer is determined, we can document it on this wiki page.
Deployment of JBESB Project
We should also provide the deployment function. Since the JBESB project maybe have different project structure and different deployment package structure, and there is no any exist WTP module type for packaging the ESB project, so
we need to define a new module type and module factory for packaging and deployment.
This is currently covered in JBIDE-2018 .
Related JIRA items
JBIDE-2384 : The main JIRA item for this work.
JBIDE-2399 : Validation of Eclipse ESB artifacts for specific SOA-P run time versions.
JBIDE-2386 : The outcome of the project structure discussion likely will impact the type of wizards created and how sample content is added to projects.
Comments