[wtp-dev] Proposal for Common Runtime Component

["Konstantin Komissarchik" <kosta@xxxxxxx>]

Currently, WTP contains two distinct runtime modeling systems. One is part of the faceted project framework. The other is part of the server tools framework. There is a bridge between them, but the bridge architecture has lead to a number of problems in the area of api usability, performance, and extensibility. This proposal attempts to address these issues by creating a common runtime modeling component to be shared by the faceted project framework and the server tools framework.

 

In broad strokes, here is the proposed scope for the new component:

 

• Extension point for defining runtime component types and versions. Runtime are composed of multiple runtime component types.
• API for creating and managing runtimes.
• Extension point for registering wizards capable of creating runtimes. Similar in concept to the new project wizard extension point.
• A wizard that allows the user to select a new runtime wizard and then delegates to that wizard for pages 2+.
• Workspace preferences page and/or a workbench view for managing the list of declared runtimes.

 

What’s outside the scope of the runtime component?

 

• Any assumption that runtimes are servers (J2EE or otherwise). That’s to continue to be handled by the server tools.
• Any notion of project association and project facets. That’s to continue to be handled by the project facets framework.

 

The new component would reside in the wst.common feature in the form of two plugins (org.eclipse.wst.common.runtime.core and org.eclipse.wst.common.runtime.ui). These plugins would not take a dependency on anything else within WTP. Both the faceted project framework and the server tools framework would take a dependency on the new runtime modeling framework.

 

Proposed implementation steps:

 

1. Factor out the runtime modeling api and extension points from the faceted project framework. Use that code to seed the new component.
2. Build out the additional functionality, particularly in the area of the UI, using code from the server tools as applicable.
3. Convert the server tools framework to use the new facility, eliminate the runtime bridge, and convert the server adapters that ship with WTP.
4. Work with adopters to aid in transition to the new api. Experience in step 3 can be used as the basis for writing a transition document.

 

API Impact

 

• All of the faceted project framework, including the code to be factored out is provisional in 1.0.x and 1.5 code lines.
• It’s unclear how much of the affected API in the server tools is provisional vs. declared.

 

Timeframe

 

• Unclear at this point. The whole process will most likely have to take place over the course of several milestones / releases, but it would be good to get the ball rolling.

 

Thoughts?

 

- Konstantin

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.