Subsystems And Features in WTP
| Subsystems And Features in WTP Subsystems And Features in WTP | |
| ||
| Introduction and 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 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]. | ||
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. | ||
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. | ||
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. | ||
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. | ||
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 current architecture document 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). | ||
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. | ||
To help keep this clearest, I'll first describe a few terms. | ||
Architecural Subsystems. 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. | ||
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. | ||
End-User Features. 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. | ||
Build Components. 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 assembled . 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. | ||
Delivered packages. 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. | ||
| End-User Features | ||
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). | ||
JST | ||
Business as usual, just what you'd think, what it currently is. | ||
WST | ||
Business as usual, just what you'd think, what it currently is. | ||
Web Development (WTP 1.0 or 1.5?) | ||
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.) | ||
XML Development (WTP 1.0 or 1.5?) | ||
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]. | ||
| Architectural Features | ||
Common Subsystem/Feature (wst-common) | ||
| ||
Web Server Subsystem/Feature (wst-server) | ||
| ||
Database Subsystem/Feature (wst-rdb) | ||
| ||
XML Subsystem/Feature (wst-xml) | ||
| ||
Web Services Subsystem/Feature (wst-ws) | ||
| ||
Web Resources Subsystem/Feature (wst-web) | ||
| ||
JST Server Subsystem/Feature (jst-server) | ||
| ||
J2EE Web Subsystem/Feature (WAR, servlets, JSPs) (jst-web) | ||
| ||
J2EE Enterprise Subsystem/Feature (EARs, EJBJar, EJBClientJar, RARs) (jst-enterprise) | ||
| ||
| Build Components | ||
General Pattern of the Build Components of a Subsystem. | ||
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. | ||
These represent function that has no UI dependencies at all. This is where most of the interesting API would be. 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 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. 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. 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 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. 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. | ||
Dependancies within a subsystem, between build components. | ||
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 vice versa ). | ||
 | ||
Dependancies between subsystems, between build components. | ||
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. | ||
 | ||
Summary of dependancies between build-components of all subsystems. | ||
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. | ||
 | ||
Additions to the general pattern. | ||
For some cases there are some additional build components for subsystems: third party code and product specific adapters. | ||
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. 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. This does add a fair amount to complexity, though. (And will need to iterate on the exact definition and content of this build-component). | ||
| Relationship to Eclipse Capabilities | ||
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. | ||
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. | ||
There are two implications. One is that we will 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. | ||
| Build Components) | ||
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. | ||
jst.enterprise_core.feature | ||
| ||
jst.enterprise_tests.feature | ||
| ||
jst.enterprise-ui.feature | ||
| ||
jst.enterprise_userdoc.feature | ||
| ||
jst.server_core.feature | ||
| ||
jst.server_product_adapters | ||
| ||
jst.server_tests.feature | ||
| ||
jst.server_ui.feature | ||
| ||
jst.server_userdoc.feature | ||
| ||
jst.web_core.feature | ||
| ||
jst.web_tests.feature | ||
| ||
jst.web_ui.feature | ||
| ||
wst.xml_core.feature | ||
| ||
wst.xml_sdk.feature | ||
| ||
wst.xml_tests.feature | ||
| ||
wst.xml_third_party_plugins | ||
| ||
wst.xml_ui.feature | ||
| ||
wst.xml_userdoc.feature | ||
| ||
wst.common_core.feature | ||
| ||
wst.common_sdk.feature | ||
| ||
wst.common_tests.feature | ||
| ||
wst.common_ui.feature | ||
| ||
wst.common_userdoc.feature | ||
| ||
wst.rdb_core.feature | ||
| ||
wst.rdb_product_adapters.feature | ||
| ||
wst.rdb-sdk.feature | ||
| ||
wst.rdb_tests.feature | ||
| ||
wst.rdb_ui.feature | ||
| ||
wst.rdb_userdoc.feature | ||
| ||
wst.server_core.feature | ||
| ||
wst.server_sdk.feature | ||
| ||
wst.server_tests.feature | ||
| ||
wst.server_ui.feature | ||
| ||
wst.server_userdoc.feature | ||
| ||
wst.web_core.feature | ||
| ||
wst.web_sdk.feature | ||
| ||
wst.web_tests.feature | ||
| ||
wst.web_third_party_plugins | ||
| ||
wst.web_ui.feature | ||
| ||
wst.web_userdoc.feature | ||
| ||
wst.ws_core.feature | ||
| ||
wst.ws_sdk.feature | ||
| ||
wst.ws_tests.feature | ||
| ||
jst.ws_third_party_plugins | ||
| ||
wst.ws_ui.feature | ||
| ||
wst.ws_userdoc.feature | ||
| ||