Jump to: navigation, search

WTP Projects and Features

Revision as of 08:37, 24 September 2007 by Deboer.ca.ibm.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

End User Features

Projects

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.