|
The Web Tooling Platform (WTP) Project is made up of two subprojects, Web Standard Tools (WST) and J2EE Standard Tools (JST).
The list of components for WST and the list of components for JST give descriptions of the components and [eventually will contain] links to that component's specific design documents.
This document describes the subsystems that these components form. These divisions into subsystems are important because they form the basis of what is available to other projects, and end-user update manager features, and features for maintenance streams. Also, it allows a high level description of internal and external dependancies.
For end-users, there is currently only one news group, eclipse.webtools. For developers, there are currently three mailing lists wtp-dev, wtp-wst-dev, and wtp-jst-dev. As the project continues, if traffic seems "heavy" for a particular component, then new mailing lists and/or news groups will be created as needed.
This document decribes the Subsystem View, Dependancies on the Eclipse Project, Dependancies on Tools Projects, Relation to other Projects and Products, Summary in Graphical form, and Deployment View.
For completeness, I'll mention our build and test component, highly modeled after the base Eclipse build and test components.
Components in this subsystem have no dependancies on other webtooling components and are not specific to web tooling functionality, but are needed by other web tooling components.
Will be an update manager feature.
Will be an update manager feature.
Will be an update manager feature.
All components pervasively required by both WST and JST. Note, there might be a few not required in short term, such as debug component, but long term it is easily imagined to be needed.
Not required by WST, but required by JST. Note: we don't rule out that we might require it someday in WST ... but no known cases currently.
Not required, though obviously want to verify co-existence.
While not an official platform project or component, we do want to verify co-existence.
In addition to the base Eclipse, the following projects/packages are prerequisites of the Webtooling Platform. GEF, EMF, and XSD are pre-req'd by enough of WST to say its always required. The JEM package is only pre-req'd by JST.
EMF, Eclipse Modeling Framework, is a way to define meta models, and then instantiate specific instances of those models. Its particularly famous for being useful to maintain models across multiple products, especially when the model may change from one release to another (the way that deployment descriptors and J2EE specs change from version to version.
The XSD, XML Schema Infoset Model, Project provides a model and API for querying detailed information about schemas and manipulating them. [Note: technically XSD Infoset is part of Technology Project, but is distributed with EMF]
GEF, Graphical Editing Framework, is a framework "on top" of SWT that makes it easier to develop sophisticated, highly customizable user interfaces that go beyond typical widgets .
The JEM package, Java EMF Model, is actually part of the VE Project. The VE
team has recently made it available as separate download from their VE build pages. In addition to allowing easier
interaction with other EMF models, it also incorporates BeanInfo into
its models (not just reflection). We use it in connection to our J2EE
EMF-based models. From what I hear, there's no ISV documentation for
this package, but the rose models that are used to create the meta model
can be found in CVS on dev.eclipse.org
/home/tools
under
/org.eclipse.jem/rose
To load into rose (from workspace) you'd also have to have
org.eclipse.emf.ecore in workspace, and define, in Rose, an EditPathMap
of WorkspaceRoot as what ever your workspace root is on your filesystem
(then it can find included files/models automatically).
Xerces. We currently ship Xerces binaries within plugin's runtimes that require them. [There's been some discussion that with OSGI classloading of PPS (Platform (bootloader), Pre-reqs, Self), that it should be easier to provide a common Xerces plugin, as long as there's no version requirements conflicts, and no custom class loaders involved, and appropriate factories used to "get" the specific parts of Xerces needed that are not part of the platforms runtime].
The following diagrams summarize the subsystem and relationships described above.
The darker shaded subsystems are accessible by end-users and other
components via update manager.
The darker shaded subsystem (orange) is accessible by end-users and other
components via update manager.
The white subsytems indicate the "links" into the WST subsystem. The JDT and JEM components indicate two
components from other projects required in JST, but not required in WST.
This section makes explicit what is currently planned to be made available as deployable features via update manager. This is paritally driven by views expressed by community users, and partially dirven by the expressed needs of other projects. It may not be the perfect "slice and dice" of the whole package that would suit everyone, but the expecation is that other projects can always download more than they need, and pick and choose the exact components they want to re-distribute.
All deployment features below will have a "binary" runtime version, and an SDK version, with all source and developer documentation.
At the hightest level, is JST and WST seperately. (With JST requireing WST).
Within JST, user's can choose all of JST, or JSP Subsystem.
Within WST, users's can choose all of WST, or the XML Subsystem (includes Schema and DTD components), or the Data Subsystem
Of Course, at any point of a decision, the choosen "subcomponent" will still "pull allong" all that its dependent on.