Google Git
Sign in
eclipse / www.eclipse.org / webtools / 234cfcb3f2518248dcded22b99723f675990164e / . / development / arch_and_design / subsystems / SubsystemsAndFeatures.xml
blob: e8da2facb4d8eb8471a6e777a48b58c934f9be7b [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="../../../wtp.xsl"?>
<html>
<head>
<meta
name="root"
content="../../../.." />
<title>Subsystems And Features in WTP</title>
</head>
<body>
<h1>Subsystems And Features in WTP</h1>
<table
border="1"
cellpadding="10"
height="50%"
width="70%">
<tbody>
<tr
align="left"
valign="middle">
<td
valign="middle"
align="left">
<blockquote style="">
<p>
<cite>
The background and status of this
document:
</cite>
</p>
<p>
<cite>
10/09/05 - this is a preliminary
draft.
</cite>
</p>
<p>
<cite>
Version 0.2 October 9, 2005.
</cite>
</p>
<p>
<cite>David Williams</cite>
</p>
</blockquote>
</td>
</tr>
</tbody>
</table>
<h2>Introduction and Background</h2>
<p>
The purpose of this document is help organize the large
thing that WTP is, into smaller chunks that can be
maintained, documented, composed into other products, etc.
[Not everything described in this document has to be
accomplished "all at once", but much progress can be made
"under the covers", gradually, and iteratively to better
partition our deliverables, builds, tests, etc. The goal,
however, is to have the fundamental pattern in place by M8
and completely implemented by M9].
</p>
<p>
WTP is now over two hundred plugins, if you include the
documentation and test plugins. While we've tried to reduce
this number -- and still will be! -- we'll never get to a
small enough number that a "list of plugins" is a very good
description of WTP.
</p>
<p>
In other words, Eclipse Members who want to extend a subset
of WTP would have a hard time picking out which plugins to
bundle. And, even if they could, there are parts of our code
and process that assume's other parts are there. For
example, if someone was only going to use a subset WTP, it
is not tenable for them to use our one "test package" --
they would either have to do a lot of "hand editing" or not
run our tests ... or, we could structure things to make it
easier for them to pick out the tests appropriate to their
subset of WTP.
</p>
<p>
Plus, there's some of our deliverables, such as user
documentation or "isv docs", which can not be packaged on a
plugin-by-plugin bases. Even our definition of "components"
is a little too fined grained for most meaningful
documentation (for example, you can not talk too much about
XML, without also talking about both DTD's and XML Schemas
... but our code plugins for xml, dtds, and schemas are
separate. Some things, like "generate XML from DTD"
logically require both XML and DTD to be present.
</p>
<p>
Hence, this document is to lay out a way to conceptualize
and specify dependencies in WTP that is more helpful Eclipse
Members who want to "extend" or "repackage" WTP. While we
can never satisfy all needs, and some will always want to
pick and choose things on a plugin by plugin bases, I think
our architectural subsystems is a more meaningful level of
composition -- and, basically, the only level we support. As
a concrete example, if someone really wanted only the
JavaScript Editor, there might be some different subset of
code plugins they could extract, but we would not provide
different packaging for docs, sdk, etc., than simply the WST
Web Development.
</p>
<p>
There has been a concept of architectural "subsystems" in
WTP for a while, with some refinements being discussed along
the way. This document is to update (make current) the
previously documented subsystem, and relate them to the
desired end-user features and build components. You can read
our
<a
href="http://www.eclipse.org/org/councils/AC/wtpsnapshot/wst_subproject_architecture.html">
current architecture document
</a>
to see the previous description of sub-systems and their
dependances. This document is just a refinement of that
document, not a fundamental change. (and, eventually, all
the information will be merged to one document).
</p>
<p>
One reason this is important to get clear on, is that it
effects the way user and SDK docs are assembled. They
should, basically, be able to be 'assembled" the same way as
the subsystem can be.
</p>
<p>
To help keep this clearest, I'll first describe a few terms.
</p>
<p>
<b>Architecural Subsystems.</b>
This term refers to a collection of plugins which "go
together" to provide a general class of function, which, as
a group, have a clear dependency relationship to other
subsystems.
</p>
<p>
This is basically the level we provide our function. For
example, if we were going to change some XML related
function, it is easy to imagine it might effect our DTD and
Schema function (and docs, and tests) but would be less
likely to effect other parts of WTP.
</p>
<p>
<b>End-User Features.</b>
This term refers to what a user can install (such as via
update manager), where the dependencies on other features
needs to be clear and obvious, for updates and maintenance
and "co-existence" with other Eclipse projects.
</p>
<p>
<b>Build Components.</b>
These are, one the one hand, literally units of the build,
where obviously dependencies have to be correct to compile.
On the other hand, these are the lowest level PDE features,
by which all other features are
<i>assembled</i>
. This level is especially important to extenders and "add
on" providers to WTP, since, sometimes, they may not want to
pre-req ALL of WTP, but parts of it, and, typically, they do
not want to assemble their own features on a
plugin-by-plugin basis, but at a feature level, to ensure
everything fits together, and "co-exists" with other
add-on's which may share some dependencies, and not share
others.
</p>
<p>
<b>Delivered packages.</b>
These correspond to the zip files that can be downloaded
from our WTP download page. I am not proposing these change
(much), just the "PDE features" that define what they are.
While we need further investigation, the "dependency" and
"include feature" parts of a PDE feature appear to work
quite well and should make the dependency and packaging
clearly specifiable.
</p>
<h2>End-User Features</h2>
<p>
These are what would be available via update manager. (We do
need some investigation here to make sure the right things
are "visible" in update manager, without requiring all
dependencies to be visible to the end-user).
</p>
<h4>JST</h4>
<p>
Business as usual, just what you'd think, what it currently
is.
</p>
<h4>WST</h4>
<p>
Business as usual, just what you'd think, what it currently
is.
</p>
<h4>Web Development (WTP 1.0 or 1.5?)</h4>
<p>
Like WST, but without Database Feature (I believe the plan
is to be using DTP project in the WTP 1.5 time-frame, so I
think advantageous to prepare for that in our 1.0
timeframe.)
</p>
<h4>XML Development (WTP 1.0 or 1.5?)</h4>
<p>
Components required for XML, Schema, and DTD development
(editing, validation, etc). I'm listing this here as a
commonly requested subsystem from user community, though am
unaware of other needs [should be easy to do, however, if
this proposal accepted].
</p>
<h2>Architectural Features</h2>
<h4>Common Subsystem/Feature (wst-common)</h4>
<ul>
<li>Common Component</li>
<ul>
<li>
Extensible Navigator
<p>
internalProvisional, proposed to move to Eclipse
Base 3.2
</p>
</li>
<li>
Tabbed Property View
<p>
internalProvisional, proposed to move to Eclipse
Base 3.2
</p>
</li>
<li>Snippets View</li>
<li>Extensible URI Resolver</li>
<li>common frameworks</li>
<ul>
<li>data operations - IDataModel</li>
<li>data wizards - provisional</li>
<li>environment framework</li>
</ul>
<li>project facets framework</li>
</ul>
<li>Validation Framework Component</li>
<li>
common.componentcore
<p>foundation for web project component</p>
</li>
<li>Internet Proxy Settings</li>
</ul>
<h4>Web Server Subsystem/Feature (wst-server)</h4>
<ul>
<li>Server Component</li>
<li>Internet Component</li>
<ul>
<li>Lightweight Server/Internet Monitor</li>
</ul>
</ul>
<h4>Database Subsystem/Feature (wst-rdb)</h4>
<ul>
<li>DB/SQL - probable DTP project merge</li>
</ul>
<h4>XML Subsystem/Feature (wst-xml)</h4>
<ul>
<li>XML Component</li>
<li>Schema Component</li>
<li>DTD Component</li>
<li>SSE Component</li>
</ul>
<h4>Web Services Subsystem/Feature (wst-ws)</h4>
<ul>
<li>WS Component</li>
<li>WSDL Component.</li>
<li>WSI Component</li>
</ul>
<h4>Web Resources Subsystem/Feature (wst-web)</h4>
<ul>
<li>HTML Component</li>
<li>CSS Component</li>
<li>JavaScript</li>
<li>Web Project Component, HTML Web Project</li>
</ul>
<h4>JST Server Subsystem/Feature (jst-server)</h4>
<ul>
<li>Server Component</li>
</ul>
<h4>
J2EE Web Subsystem/Feature (WAR, servlets, JSPs) (jst-web)
</h4>
<ul>
<li>
J2EE Core Web Model Component [Issue: not currently
packaged this way]
</li>
<li>
Servlet Component/J2EEWebProject ... some API, create
web component API
</li>
<li>
JSP Component ... some internal provisional .. need
better design documents
</li>
<li>WS Web Component (JAXRPC)</li>
</ul>
<h4>
J2EE Enterprise Subsystem/Feature (EARs, EJBJar,
EJBClientJar, RARs) (jst-enterprise)
</h4>
<ul>
<li>
J2EE Core Enterprise Model Component [Issue: not
currently packaged this way]
</li>
<li>EJB Component</li>
<li>WS Component</li>
</ul>
<h2>Build Components</h2>
<h4>General Pattern of the Build Components of a Subsystem.</h4>
<p>
Each subsystem follows a predictable pattern, with minor
deviations here and there.
</p>
<p>
Each of the following "categories" would be one build
component, for the subsystem -- for 5 per subsystem, which,
yes, means 45 total build components. Luckily, they all
follow a standard pattern in their make up and dependencies.
</p>
<ul>
<li>
Model/Core plugins (
<b>-core</b>
)
</li>
<p>
These represent function that has no UI dependencies at
all. This is where most of the interesting API would be.
</p>
<li>
UI plugins and Info plugins (
<b>-ui</b>
)
</li>
<p>
The "UI" portion is hopefully obvious ... anything
related to the display, presentation, editors, menus,
wizards, preference pages (though, note, many
preferences still have a model or core aspect). In
particular, any thing that pre-req's SWT (directly or
indirectly) is considered "UI").
</p>
<p>
The info-plugins consist of infopop's (dynamic help)
which is tied to the UI via "IDs" but has links to the
user-docs. These info plugins may have NL fragments, but
those are "pure assembly", added to an install of other
components, and not part of an WTP build or official
deliverable.
</p>
<li>
User Doc plugins (
<b>-userdocs</b>
)
</li>
<p>
User docs consists of the xhtml documentation that is
"browsable" and searchable. They can be packaged as
"just docs" for serving on the web via an "info center"
or shipped with product code for offline access via the
Eclipse help system. These are "just assembled" and do
not need the code to build, although they are typically
assembled with the code build, to ensure there is the
same integration process as with other component teams.
</p>
<p>
The point of putting them in well defined places in the
architecture is to define what content goes where, so as
new products bundle our subsystems, the documentation
provided is appropriate. These can have NL fragments for
translated versions of docs (again, pure "assembly", not
part of any WTP build or deliverable.
</p>
<li>
JUnit Tests and Performance Tests (
<b>-tests</b>
)
</li>
<p>
The JUnit tests are an important part of every build,
since they (somewhat) verify the integrity of the build
without complete testing "by hand".
</p>
<p>
While performance tests are not ran at the same time as
the build or other JUnit tests (because the performance
tests are ran on a pristine machine) there is little
cost with building and packaging them together.
</p>
<p>
The most important thing is that someone getting only a
part of WTP, should be able to get the tests relevant to
that part, and those tests should still succeed without
tweaking or re-packaging or changing of scripts.
</p>
<li>
SKD components (
<b>-sdk</b>
)
<p>
Source plugin, ISV Documentation, example plugins,
sdk tools, if any.
</p>
</li>
</ul>
<h5>
Dependancies within a subsystem, between build components.
</h5>
<p>
The following figure shows how the build components within
one subsystem are dependant on each other, using
'wst-common' as the example. Here 'depends on' (labeled
"uses" in the figure) means that plugins in one plugin, can
'require' plugins in the dependent build-component. For
example, things in any common-ui component plugin can use
any plugin in common-core component plugins (but not
<i>vice versa</i>
).
</p>
<img
src="./images/GeneralPattern.gif"
alt="Common pattern of inter-subsystem dependencies"
border="1"
align="bottom" />
<h5>
Dependancies between subsystems, between build components.
</h5>
<p>
The following figure shows how build components are
specified to be dependent on each other, using wst-xml and
wst-common as examples. Note that for "plugin dependancies"
the rule is that anything "on a path" would be allowable,
though not always shown expllicitly in the figure. For
example, a plugin in xml-ui feature could require a plugin
in common-core, even though there is no direct "uses" arrow
between the two ... there is an indirect one though in that
xml-ui uses xml-core which uses common-core.
</p>
<img
src="./images/GeneralPatternCrossSystems.gif"
alt="Common pattern of intra-subsystem dependencies"
border="1"
align="bottom" />
<h5>
Summary of dependancies between build-components of all
subsystems.
</h5>
<p>
The following shows a summary of how the components from
subsystems are dependent on each other (the exact UI and
core paths are not shown, but UI and core would be used in
the PDE features). Also not shown are the dependancies on
third-party or how product-adapter components.
</p>
<img
src="./images/WTPSubsystems.gif"
alt="Summary pattern of WTP dependencies"
border="1"
align="bottom" />
<h4>Additions to the general pattern.</h4>
<p>
For some cases there are some additional build components
for subsystems: third party code and product specific
adapters.
</p>
<ul>
<li>
Third Party Code (
<b>third-party-code</b>
)
</li>
<p>
These deviate from the general pattern a little, since
for many purposes they are summarized as "a collection
of plugins", in reality, each should be a feature-plugin
pair (so future updates are easier, and in principle
could be made available from anywhere, such as the
original third-party source!.)
</p>
<p>
We only package and distribute non-SDK version of the
third-party code.
</p>
<li>
Product Specific Adapters (
<b>product-adapters</b>
)
</li>
<p>
While we do not ship "other products" in WTP, we do ship
adapters (or "configuration definitions") for some other
products ... in the Database components and the
JST-Server components. We can split those out separately
for purposes of builds, maintenance releases, etc., so
this allows WTP extenders to decide to include or not
include them, without having to create new features of
the core functionality. This is important for proper
"co-existence" if an end-user decided to install
products from two WTP extenders ... we need to provide
an easy way for only one intact version of the "core
features" to be used in those cases.
</p>
<p>
This also allows the future growth that these "product
adapters" can be "hosted" by the specific product sites,
instead of WTP per se.
</p>
<p>
This does add a fair amount to complexity, though. (And
will need to iterate on the exact definition and content
of this build-component).
</p>
</ul>
<h2>Relationship to Eclipse Capabilities</h2>
<p>
Eclipse has the ability to turn certain capabilities on or
off. For example, in the base Eclipse install, you could
turn off Plugin development if you were not going to use
that. The purpose of this aspect of Eclipse is to simplify
the interface for the user who does not need certain things.
</p>
<p>
The distinctions in this document are often highly related
to "Eclipse Capabilities", but is not a substitute for the
work we still need to do in that area, and this document is
to solve a different set of problems.
</p>
<p>
There are two implications. One is that we
<b>will</b>
want to define some "capabilities" in WTP that correspond to
our subsystems. For example, even if RDB is installed, we
might still have a capability for database work, so users
who are not using it, will not have to see certain menu
options, etc. But there are other, more detailed kinds of
capabilities that we might implement some day. A common
suggestion is that some users "produce" certain components,
such as web services, or EJBs, etc, but other users only
"consume" them during their development. So, the "consuming"
user could have a simplified experience if we had "produce
and consume" capabilities where appropriate. Our
"capabilities" work has yet to be designed and planned for,
but the point I wanted to make here was that in some cases
the same effect might be achieved by what extenders could
"package" (e.g. leave out RDB if their product didn't need
it), but in come cases it could not be -- we will not offer
separate "PDE features" for the produce vs. consume
dimension, but (hopefully) someday will offer that improved
user experience through Eclipse capabilities.
</p>
<h2>Build Components)</h2>
<p>
The listed plugins are preliminary, for review. Its my
current "best guess" of the right partitions, but will need
careful study and review from all component teams.
Eventually, these exact lists and relationships will be
defined and document "in the code" (via the feature.xml
files) but until then, thought this would help get a head
start on reviewing some concrete proposal.
</p>
<h4>jst.enterprise_core.feature</h4>
<ul>
<li>org.eclipse.jst.j2ee</li>
<li>org.eclipse.jst.j2ee.core</li>
<li>org.eclipse.jst.j2ee.ejb</li>
<li>org.eclipse.jst.j2ee.ejb.annotation.model</li>
<li>org.eclipse.jst.j2ee.ejb.annotations.emitter</li>
<li>org.eclipse.jst.j2ee.ejb.annotations.xdoclet</li>
<li>org.eclipse.jst.j2ee.jca</li>
<li>org.eclipse.jst.j2ee.webservice</li>
</ul>
<h4>jst.enterprise_tests.feature</h4>
<ul>
<li>org.eclipse.jst.j2ee.core.tests</li>
<li>org.eclipse.jst.j2ee.core.tests.performance</li>
<li>org.eclipse.jst.j2ee.tests</li>
<li>org.eclipse.jst.j2ee.tests.performance</li>
<li>org.eclipse.jst.validation.sample</li>
<li>org.eclipse.jst.validation.test</li>
<li>org.eclipse.jst.ws.tests</li>
<li>org.eclipse.jst.ws.tests.performance</li>
</ul>
<h4>jst.enterprise-ui.feature</h4>
<ul>
<li>org.eclipse.jst.ejb.ui</li>
<li>org.eclipse.jst.j2ee.ejb.annotations.ui</li>
<li>org.eclipse.jst.j2ee.jca.ui</li>
<li>org.eclipse.jst.j2ee.navigator.ui</li>
<li>org.eclipse.jst.j2ee.ui</li>
<li>org.eclipse.jst.j2ee.webservice.ui</li>
<li>org.eclipse.jst.ws.axis.creation.ui</li>
<li>org.eclipse.jst.ws.consumption</li>
<li>org.eclipse.jst.ws.consumption.ui</li>
<li>org.eclipse.jst.ws.creation.ui</li>
<li>org.eclipse.jst.ws.uddiregistry</li>
<li>org.eclipse.jst.ws.ui</li>
<li>org.eclipse.jst.j2ee.infopop</li>
<li>org.eclipse.jst.ws.axis.infopop</li>
<li>org.eclipse.jst.ws.creation.ejb.ui</li>
</ul>
<h4>jst.enterprise_userdoc.feature</h4>
<ul>
<li>org.eclipse.jst.ejb.doc.user</li>
</ul>
<h4>jst.server_core.feature</h4>
<ul>
<li>org.eclipse.jst.server.core</li>
<li>org.eclipse.jst.server.generic.core</li>
</ul>
<h4>jst.server_product_adapters</h4>
<ul>
<li>org.eclipse.jst.server.generic.serverdefinitions</li>
<li>org.eclipse.jst.server.tomcat.core</li>
<li>org.eclipse.jst.server.tomcat.core.tests</li>
<li>org.eclipse.jst.server.tomcat.tests.performance</li>
<li>org.eclipse.jst.server.tomcat.ui</li>
<li>org.eclipse.jst.server.tomcat.ui.tests</li>
<li>org.eclipse.jst.server.websphere.core</li>
</ul>
<h4>jst.server_tests.feature</h4>
<ul>
<li>org.eclipse.jst.server.core.tests</li>
<li>org.eclipse.jst.server.generic.tests</li>
<li>org.eclipse.jst.server.tomcat.core.tests</li>
<li>org.eclipse.jst.server.tomcat.tests.performance</li>
<li>org.eclipse.jst.server.tomcat.ui.tests</li>
<li>org.eclipse.jst.server.ui.tests</li>
</ul>
<h4>jst.server_ui.feature</h4>
<ul>
<li>org.eclipse.jst.server.generic.ui</li>
<li>org.eclipse.jst.server.ui</li>
<li>org.eclipse.jst.server.ui.infopop</li>
</ul>
<h4>jst.server_userdoc.feature</h4>
<ul>
<li>org.eclipse.jst.server.ui.doc.user</li>
</ul>
<h4>jst.web_core.feature</h4>
<ul>
<li>org.eclipse.jst.common.annotations.controller</li>
<li>org.eclipse.jst.common.annotations.core</li>
<li>org.eclipse.jst.common.frameworks</li>
<li>org.eclipse.jst.common.navigator.java</li>
<li>org.eclipse.jst.j2ee.web</li>
<li>org.eclipse.jst.jsp.core</li>
<li>org.eclipse.jst.ws</li>
<li>org.eclipse.jst.ws.axis.consumption.core</li>
</ul>
<h4>jst.web_tests.feature</h4>
<ul>
<li>org.eclipse.jst.jsp.core.tests</li>
<li>org.eclipse.jst.jsp.tests.encoding</li>
<li>org.eclipse.jst.jsp.ui.tests</li>
<li>org.eclipse.jst.jsp.ui.tests.performance</li>
<li>org.eclipse.jst.servlet.tests</li>
</ul>
<h4>jst.web_ui.feature</h4>
<ul>
<li>org.eclipse.jst.common.annotations.ui</li>
<li>org.eclipse.jst.jsp.ui</li>
<li>org.eclipse.jst.servlet.ui</li>
<li>org.eclipse.jst.ws.axis.consumption.ui</li>
<li>org.eclipse.jst.jsp.ui.infopop</li>
<li>org.eclipse.jst.ws.consumption.infopop</li>
<li>org.eclipse.jst.ws.infopop</li>
</ul>
<h4>wst.xml_core.feature</h4>
<ul>
<li>org.eclipse.wst.dtd.core</li>
<li>org.eclipse.wst.sse.core</li>
<li>org.eclipse.wst.xml.core</li>
<li>org.eclipse.wst.xsd.core</li>
</ul>
<h4>wst.xml_sdk.feature</h4>
<ul>
<li>org.eclipse.wst.xml.source</li>
</ul>
<h4>wst.xml_tests.feature</h4>
<ul>
<li>org.eclipse.wst.dtd.ui.tests</li>
<li>org.eclipse.wst.sse.core.tests</li>
<li>org.eclipse.wst.sse.ui.tests</li>
<li>org.eclipse.wst.sse.ui.tests.performance</li>
<li>org.eclipse.wst.xml.core.tests</li>
<li>org.eclipse.wst.xml.tests.encoding</li>
<li>org.eclipse.wst.xml.ui.tests</li>
<li>org.eclipse.wst.xml.ui.tests.performance</li>
<li>org.eclipse.wst.xml.validation.tests</li>
<li>org.eclipse.wst.xsd.tests.performance</li>
<li>org.eclipse.wst.xsd.validation.tests</li>
</ul>
<h4>wst.xml_third_party_plugins</h4>
<ul>
<li>org.apache.xerces</li>
<li>org.apache.xerces.feature</li>
</ul>
<h4>wst.xml_ui.feature</h4>
<ul>
<li>org.eclipse.wst.dtd.ui</li>
<li>org.eclipse.wst.sse.ui</li>
<li>org.eclipse.wst.xml.ui</li>
<li>org.eclipse.wst.xsd.ui</li>
<li>org.eclipse.wst.dtd.ui.infopop</li>
<li>org.eclipse.wst.sse.ui.infopop</li>
<li>org.eclipse.wst.xml.ui.infopop</li>
</ul>
<h4>wst.xml_userdoc.feature</h4>
<ul>
<li>org.eclipse.wst.dtdeditor.doc.user</li>
<li>org.eclipse.wst.sse.doc.user</li>
<li>org.eclipse.wst.xmleditor.doc.user</li>
<li>org.eclipse.wst.xsdeditor.doc.user</li>
</ul>
<h4>wst.common_core.feature</h4>
<ul>
<li>org.eclipse.wst.command.env</li>
<li>org.eclipse.wst.command.env.core</li>
<li>org.eclipse.wst.common.emf</li>
<li>org.eclipse.wst.common.environment</li>
<li>org.eclipse.wst.common.frameworks</li>
<li>org.eclipse.wst.common.modulecore</li>
<li>org.eclipse.wst.common.project.facet.core</li>
<li>org.eclipse.wst.common.uriresolver</li>
<li>org.eclipse.wst.internet.cache</li>
<li>org.eclipse.wst.validation</li>
</ul>
<h4>wst.common_sdk.feature</h4>
<ul>
<li>org.eclipse.wst.common.isvdoc</li>
<li>org.eclipse.wst.common.sdk.source</li>
</ul>
<h4>wst.common_tests.feature</h4>
<ul>
<li>org.eclipse.wst.common.tests</li>
<li>org.eclipse.wst.common.tests.collector</li>
<li>org.eclipse.wst.common.tests.performance</li>
<li>org.eclipse.wst.common.tests.ui</li>
<li>org.eclipse.wst.internet.cache.tests</li>
</ul>
<h4>wst.common_ui.feature</h4>
<ul>
<li>org.eclipse.wst.command.env.ui</li>
<li>org.eclipse.wst.common.frameworks.ui</li>
<li>org.eclipse.wst.common.navigator.views</li>
<li>org.eclipse.wst.common.navigator.workbench</li>
<li>org.eclipse.wst.common.project.facet.ui</li>
<li>org.eclipse.wst.common.snippets</li>
<li>org.eclipse.wst.common.ui</li>
<li>org.eclipse.wst.common.ui.properties</li>
<li>org.eclipse.wst.internet.proxy</li>
<li>org.eclipse.wst.validation.ui</li>
<li>org.eclipse.wst.common.infopop</li>
</ul>
<h4>wst.common_userdoc.feature</h4>
<ul>
<li>org.eclipse.wst.common.user.doc</li>
</ul>
<h4>wst.rdb_core.feature</h4>
<ul>
<li>org.eclipse.wst.rdb.core</li>
<li>org.eclipse.wst.rdb.data.core</li>
<li>org.eclipse.wst.rdb.models.sql</li>
</ul>
<h4>wst.rdb_product_adapters.feature</h4>
<ul>
<li>org.eclipse.wst.rdb.derby</li>
<li>org.eclipse.wst.rdb.mysql</li>
<li>org.eclipse.wst.rdb.dbdefinition.db2.iseries</li>
<li>org.eclipse.wst.rdb.dbdefinition.db2.luw</li>
<li>org.eclipse.wst.rdb.dbdefinition.db2.zseries</li>
<li>org.eclipse.wst.rdb.dbdefinition.derby</li>
<li>org.eclipse.wst.rdb.dbdefinition.informix</li>
<li>org.eclipse.wst.rdb.dbdefinition.mysql</li>
<li>org.eclipse.wst.rdb.dbdefinition.oracle</li>
<li>org.eclipse.wst.rdb.dbdefinition.sqlserver</li>
<li>org.eclipse.wst.rdb.dbdefinition.sybase</li>
</ul>
<h4>wst.rdb-sdk.feature</h4>
<ul>
<li>org.eclipse.wst.rdb.source</li>
<li>org.eclipse.wst.rdp.isvdoc</li>
</ul>
<h4>wst.rdb_tests.feature</h4>
<ul>
<li>org.eclipse.wst.rdb.tests.performance</li>
</ul>
<h4>wst.rdb_ui.feature</h4>
<ul>
<li>org.eclipse.wst.rdb.connection.ui</li>
<li>org.eclipse.wst.rdb.core.ui</li>
<li>org.eclipse.wst.rdb.data.ui</li>
<li>org.eclipse.wst.rdb.derby.ui</li>
<li>org.eclipse.wst.rdb.fe.ui</li>
<li>org.eclipse.wst.rdb.fe.ui.actions</li>
<li>org.eclipse.wst.rdb.models.dbdefinition</li>
<li>org.eclipse.wst.rdb.models.sql.edit</li>
<li>org.eclipse.wst.rdb.outputview</li>
<li>org.eclipse.wst.rdb.server.extensions</li>
<li>org.eclipse.wst.rdb.server.ui</li>
<li>org.eclipse.wst.rdb.sqleditor</li>
<li>org.eclipse.wst.rdb.sqlscrapbook</li>
<li>org.eclipse.wst.rdb.connection.ui.infopop</li>
<li>org.eclipse.wst.rdb.fe.ui.infopop</li>
<li>org.eclipse.wst.rdb.outputview.infopop</li>
<li>org.eclipse.wst.rdb.server.ui.infopop</li>
<li>org.eclipse.wst.rdb.sqleditor.infopop</li>
<li>org.eclipse.wst.rdb.sqlscrapbook.infopop</li>
</ul>
<h4>wst.rdb_userdoc.feature</h4>
<ul>
<li>org.eclipse.wst.datatools.connection.ui.doc.user</li>
<li>org.eclipse.wst.datatools.fe.ui.doc.user</li>
<li>org.eclipse.wst.datatools.server.ui.doc.user</li>
</ul>
<h4>wst.server_core.feature</h4>
<ul>
<li>org.eclipse.wst.internet.monitor.core</li>
<li>org.eclipse.wst.server.core</li>
</ul>
<h4>wst.server_sdk.feature</h4>
<ul>
<li>org.eclipse.wst.rdb.isvdoc</li>
<li>org.eclipse.wst.server.source</li>
</ul>
<h4>wst.server_tests.feature</h4>
<ul>
<li>org.eclipse.wst.internet.monitor.core.tests</li>
<li>org.eclipse.wst.internet.monitor.ui.tests</li>
<li>org.eclipse.wst.server.core.tests</li>
<li>org.eclipse.wst.server.tests.performance</li>
<li>org.eclipse.wst.server.ui.tests</li>
</ul>
<h4>wst.server_ui.feature</h4>
<ul>
<li>org.eclipse.wst.internet.monitor.ui</li>
<li>org.eclipse.wst.server.ui</li>
<li>org.eclipse.wst.server.ui.infopop</li>
</ul>
<h4>wst.server_userdoc.feature</h4>
<ul>
<li>org.eclipse.wst.server.ui.doc.user</li>
</ul>
<h4>wst.web_core.feature</h4>
<ul>
<li>org.eclipse.wst.common.emfworkbench.integration</li>
<li>org.eclipse.wst.css.core</li>
<li>org.eclipse.wst.html.core</li>
<li>org.eclipse.wst.javascript.core</li>
<li>org.eclipse.wst.web</li>
</ul>
<h4>wst.web_sdk.feature</h4>
<ul>
<li>org.eclipse.wst.web.isv.doc</li>
<li>org.eclipse.wst.web.source</li>
</ul>
<h4>wst.web_tests.feature</h4>
<ul>
<li>org.eclipse.wst.css.core.tests</li>
<li>org.eclipse.wst.css.tests.encoding</li>
<li>org.eclipse.wst.css.ui.tests</li>
<li>org.eclipse.wst.css.ui.tests.performance</li>
<li>org.eclipse.wst.html.core.tests</li>
<li>org.eclipse.wst.html.tests.encoding</li>
<li>org.eclipse.wst.html.ui.tests</li>
<li>org.eclipse.wst.html.ui.tests.performance</li>
</ul>
<h4>wst.web_third_party_plugins</h4>
<ul>
<li>org.eclipse.wst.html.standard.dtds</li>
</ul>
<h4>wst.web_ui.feature</h4>
<ul>
<li>org.eclipse.wst.css.ui</li>
<li>org.eclipse.wst.html.ui</li>
<li>org.eclipse.wst.javascript.ui</li>
<li>org.eclipse.wst.web.ui</li>
<li>org.eclipse.wst.css.ui.infopop</li>
<li>org.eclipse.wst.html.ui.infopop</li>
<li>org.eclipse.wst.javascript.ui.infopop</li>
</ul>
<h4>wst.web_userdoc.feature</h4>
<ul>
<li>org.eclipse.wst.webtools.doc.user</li>
</ul>
<h4>wst.ws_core.feature</h4>
<ul>
<li>org.eclipse.wst.ws</li>
<li>org.eclipse.wst.ws.parser</li>
<li>org.eclipse.wst.wsdl</li>
<li>org.eclipse.wst.wsi</li>
</ul>
<h4>wst.ws_sdk.feature</h4>
<ul>
<li>org.eclipse.wst.webservice.source</li>
</ul>
<h4>wst.ws_tests.feature</h4>
<ul>
<li>org.eclipse.wst.ws.tests</li>
<li>org.eclipse.wst.wsdl.tests</li>
<li>org.eclipse.wst.wsdl.tests.performance</li>
<li>org.eclipse.wst.wsdl.tests.ui</li>
<li>org.eclipse.wst.wsdl.validation.tests</li>
<li>org.eclipse.wst.wsi.tests</li>
</ul>
<h4>jst.ws_third_party_plugins</h4>
<ul>
<li>org.apache.wsil4j</li>
<li>org.uddi4j</li>
<li>org.wsdl4j</li>
<li>org.apache.wsil4j.feature</li>
<li>org.uddi4j.feature</li>
<li>org.wsdl4j.feature</li>
</ul>
<h4>wst.ws_ui.feature</h4>
<ul>
<li>org.eclipse.wst.ws.explorer</li>
<li>org.eclipse.wst.ws.ui</li>
<li>org.eclipse.wst.wsdl.ui</li>
<li>org.eclipse.wst.wsdl.validation</li>
<li>org.eclipse.wst.wsi.ui</li>
<li>org.eclipse.wst.ws.infopop</li>
<li>org.eclipse.wst.wsdl.ui.doc.user</li>
<li>org.eclipse.wst.wsi.ui.doc.user</li>
</ul>
<h4>wst.ws_userdoc.feature</h4>
<ul>
<li>org.eclipse.wst.wsdleditor.doc.user</li>
</ul>
</body>
</html>