WTP Projects and Features

WTP Projects and Features

Introduction & Background

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 currently exists (and we'll try to note what doesn't match reality), but it does describe the fundamental pattern and direction for WTP.

WTP is now over two hundred plugins and sixty five features, 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. 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 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.

There's also 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.

Hence, this document is to lay out a way to conceptualize and specify dependencies in WTP that is more helpful to 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, 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.

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 subsystems, and relate them to the desired end-user features and build components. You can read our current architecture document to see the previous description of sub-systems and their dependences. This document is just a refinement of that document, not a fundamental change. (and, eventually, all the information will be merged to one document).

Finally, this document is a long awaited update to the information found here: http://www.eclipse.org/webtools/development/arch_and_design/subsystems/SubsystemsAndFeatures.html

Build Components

Each subsystem follows a predictable pattern, with minor deviations here and there.

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.

• Model/Core plugins ( -core )

These represent function that has no UI dependencies at all. This is where most of the interesting API would be.

• UI plugins and Info plugins ( -ui )

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".

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.

• User Doc plugins ( -userdocs )

User docs consists of the online 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.

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.

• JUnit Tests and Performance Tests ( -tests )

The JUnit tests are an important part of every build, since they (somewhat) verify the integrity of the build without complete testing "by hand".

While performance tests are not run 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.

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.

• SDK components ( -sdk )

Source plugin, ISV Documentation, example plugins, SDK tools, if any.

For some cases there are some additional build components for subsystems:

• Third Party Code ( -third-party-code )

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!)

We only package and distribute non-SDK version of the third-party code.

• Product Specific Adapters ( -product-adapters )

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.

This also allows the future growth that these "product adapters" can be hosted by the specific product sites, instead of WTP per se.

Relationship to Capabilities

Eclipse has the ability to enable or disable certain capabilities within the IDE. For example, The Eclipse SDK defines capabilities for PDE that allow you to 'hide' the plugin development function even though it is installed. Capabilities only affect the UI - the same plugins are still installed and may load as usual. The purpose of capabilities is to simplify the UI and reduce the clutter of unused function.

The structure of projects and features is orthogonal and yet complimentary to capabilities. Defining smaller grained components allows an adopter to select only the subset of WTP that is applicable to their users, and thus not require capabilities to hide this function. If a component is required by dependencies or only infrequently used, capabilities could be used to hide this function to simplify the user experience.

We will not discuss capabilities here other than to make this clarification.