Bugzilla – Full Text Bug Listing
| Summary: | Wizard to export EAR and WAR should allow customization | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Danny Ju <danny.ju> | ||||||||
| Component: | jst.j2ee | Assignee: | Konstantin Komissarchik <konstantin> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | cbridgha, jsholl, konstantin | ||||||||
| Version: | 2.0 | ||||||||||
| Target Milestone: | 3.0 M3 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
David, Please take a look at creating a patch for this. Chuck, Any initial objections to making the EAR and WAR wizards be extensible by allowing additional UI widgets to be added at the bottom of the first page via an extension point? We'd like to implement this for 2.0 as we are currently in a rather unattractive situation of having to replace these wizards in order to provider additional options. Can;t commit for 2.0 Danny, Could you take a look at creating a patch for this for 3.0? I'll take this one. I have added extension points and API to the archive export wizards to meet the following requirements:
1. It should be possible for server vendors to supply operations and UI to extend the default archive export process. This should appear as seamless as possible to the user. Since often the contributed UI will be very small (such a single checkbox), the solution should avoid presenting this UI on a separate wizard page.
2. The user should have full control of whether or not server-specific extensions are invoked. This should be made obvious.
3. It should be obvious which UI elements are contributed as the result of selecting the runtime.
On the core side there is an extension point that defines "archive export participants", specifying the conditions under which the participant should be enabled and providing a factory for constructing the corresponding data model and operation.
Here is an example that declares an archive export participant that's applicable to WebLogic Server 9.2+ and web or ear projects.
<extension point="org.eclipse.jst.j2ee.archiveExportParticipants">
<participant id="wlsArchiveExportParticipant">
<runtime-component type="com.bea.weblogic" version="[9.2"/>
<factory class="com.bea.workshop.wls.core.export.internal.WlsArchiveExportParticipant"/>
<enablement>
<or>
<test
forcePluginActivation="true"
property="org.eclipse.wst.common.project.facet.core.projectFacet"
value="jst.web"/>
<test
forcePluginActivation="true"
property="org.eclipse.wst.common.project.facet.core.projectFacet"
value="jst.ear"/>
</or>
</enablement>
</participant>
</extension>
The export participants are surfaced in IJ2EEComponentExportDataModelProperties as three new properties:
OPTIMIZE_FOR_SPECIFIC_RUNTIME - Boolean
RUNTIME - IRuntime
RUNTIME_SPECIFIC_PARTICIPANTS - List<IArchiveExportParticipantData>; Holds information about currently-applicable participants including their data models.
On the UI side, there is another extension point that associates a "panel factory" with an archive export participant. Here is an example:
<extension point="org.eclipse.jst.j2ee.ui.archiveExportParticipantPanels">
<panel-factory
archiveExportParticipantId="com.bea.workshop.wls.core.wlsArchiveExportParticipant"
class="com.bea.workshop.wls.ui.export.internal.WlsArchiveExportParticipantPanelFactory"/>
</extension>
An export participant isn't required to have a UI panel. Panels for any applicable export participants are displayed directly underneath the combo that allows the user to select the runtime. This makes the association real obvious.
All new api has been documented. This change doesn't affect any existing behavior and has been extensively tested. Will add the patch and a screen shot for anyone who want to review this.
Created attachment 81897 [details]
Screen capture showing the new UI
Attached screen capture shows the new UI. The "Pre-compile JSP files" checkbox directly underneath the runtimes combo is supplied by a vendor plugin using the facility provided by this enhancement.
When user deselects the "optimize" checkbox, the runtimes combo and any participant panels are disabled.
The runtime combo contains all known runtimes that are compatible with the project.
If project targets one or more runtime, then the default value for the optimize checkbox is true and the default selection of the runtime combo is the primary runtime.
If project doesn't target a runtime, the optimize checkbox is off.
Created attachment 81898 [details]
Patch
You're sreenshot looks good (haven't had a chance to look at the patch yet). I was wondering though, what happens if different runtimes want to present different UI controls? Is the idea that those controls would be placed inside the Target Runtime group in place of the "Pre-compile JSP files" checkbox included in your screenshot? I ask because the idea of allowing extenders to contribute UI to existing main pages has come up in the past and we never had the time to figure out a good general case solution for the IDataModelWizard framework. If this is what you're doing, then I wonder if it could be generalized in such a way that all existing IDataModelWizardPages could be extendable. I realize that this, however, is a very specific case because the controls are built based on the combo selection. The space directly underneath the runtimes combo (inside the target runtime frame) is populated dynamically based on selection within the combo. The wizard page listens to the RUNTIME_SPECIFIC_PARTICIPANTS property (which is a list). When that property changes, the composite beneath the runtime combo is disposed. Then the wizard goes through the new list of participants. For each participant, it asks the UI extension point if there is a panel factory for that participant id. If there is, the panel factory gets a chance to contribute it's ui to the new composite that is being constructed. The parent composite uses a grid layout with 1 column, so multiple UI contributions will get arranged vertically within the composite. The panel factory is given the contributor's data model object, so the UI can be properly bound to the model. This could certainly be generalized given more effort. The tricky part is figuring out how to deal with wanting to give people multiple "insertion points". For instance in the archive export wizard, in addition to allowing people to specify UI to appear beneath the runtime combo, it might be beneficial to allow UI to be added at the bottom of the page (for more globally-relevant options). I think this can be handled via an extra attribute on the UI extension point identifying the insertion point. The page would then call into the framework during construction of page's UI, essentially saying "insertion point X is over here". If we are going to do this, I wonder if it makes sense to generalize this even beyond the data model framework. If we got real ambitious, we could even try to contribute this to JFace. ;) Created attachment 81976 [details]
Screen Cast
Attaching the screen cast (Adobe Flash required) showing the new UI in action.
Committed changes to HEAD. Haven't released them since there are other unreleased changes in those plugins that I am not sure about. We can keep tuning this further , but I want to make sure that this gets into M3 and into the hands of early adopters who can provide the necessary feedback in time for us to react before api freeze. |
This is a feature enhancement request for WTP. The Wizard to export EAR and WAR in WTP only allows user to set a fixed set of options("Export Source file" and "Overwrite existing file") to control the export operation. There are use cases we'd like present user with more options through UI e.g. run JSP compiler or run EJBGen. The wizard should provide an extension point to allow plug-ins to register a class which 1. can customize the UI. 2. has access to ExportDataModelProvider and be able to set property based on user selection.