New Help for Old Friends IV
This page to to collect miscellaneous notes and pointers to changes coming up in the WTP 3.1 (Galileo) release. Its purpose it to be a central "jump off" point for those adopters of WTP 3.0 that are moving to WTP 3.1. Most of this information may be already contained in various mailing lists and Bugzilla reports, but it is believed best to have a central place to get people started.
Adopters: if you run into trouble or notice things that are not covered here, please let us know (firstname.lastname@example.org is a good place). This will not only help us keep these notes up to date, but will help us better learn, over time, the discipline of "platform development" and help make sure we learn to provide compatible APIs, migration instructions, etc., in the future. It is not always easy, but our intent is to make it as simple and painless as possible for adopters to use WTP as a true platform.
One thing we have learned in the past is that some adopters do not move with us to every new release. Some early adopters went from 0.7 directly to 1.5, for example. Unfortunately, it is hard for us to present the information in that way, covering perhaps multiple changes, but hopefully as we develop these for each release, they will all flow together to aid adopters.
Note: as these notes develop and grow in number, they may occasionally be re-organized into categories, etc.
- 1 Versioning changes
- 2 Source Editing Components
- 3 Web Services Components
- 4 Java EE Tools Components
- 5 JavaServer Faces
- 6 releng
- 7 Reference
Remember you can always view the versions and version changes for each build, by following the "Versioning Information" link on each build page. For example, see the one for WTP 3.1 M4.
Following are some of the noteworthy 'minor' field changes.
minor versions incremented
The Faceted Project framework needed to increment the minor version in the 3.1 code stream to reflect the changes that happened in that code.
|org.eclipse.wst.common.project.facet.core||1.3.100 -> 1.4.0|
|org.eclipse.wst.common.project.facet.ui||1.3.100 -> 1.4.0|
|org.eclipse.jst.common.project.facet.core||1.3.100 -> 1.4.0|
|org.eclipse.jst.common.project.facet.ui||1.3.100 -> 1.4.0|
jst.common features removed
To quote mailing list message:
Two features in the WTP Common Project are being eliminated as part of a work item planned for the 3.1 release. Complete details can be found here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=200247 (see comment #9 in particular)
Due to the low-level and ambiguous nature of features that are being eliminated, I do not think that anyone will be impacted by this, but in case there is a product out there that declares an explicit dependency on these two features:
it will need to change to declare dependency on these two features instead:
Anyone who takes a dependency on one of the higher-level features, will not be affected by this change. None of the existing plugins are being changed.
|org.eclipse.wst.xml.ui||1.0.4xx -> 1.1.0||Refactoring of Outline View Configuration (246024)|
|org.eclipse.wst.wsdl||1.1.3xx -> 1.2.0||Bug 197197|
|javax.wsdl||1.4.x -> 1.5.x||Bug 197197||Both versions of the plugin are actually currently in WTP, however if your plugin depends on both this plugin and org.eclipse.wst.wsdl, you are required to update this plugin dependency version number as well.|
|Allow multiple Server profilers||270503|| ADOPTERS IMPACT: From a end-user point view, current adopters are not impacted by this change. The changes are structured in a way that if there is only one profiler, that profiler will made the default. Now if there more than one, and the user hasn't selected any profiler, the first profiler loaded will be selected. If the user selected a profiler using the UI, that profiler will be used across WTP.
USER IMPACT: User will now be able to select a profiler if an adopter product contains more than one profiler implementations. This is done through a Workspace Preference dialog inside the Server/Profiler category.
DOC IMPACT: good point, I didn't cover this area. There would definitely be a need for docs to cover the new UI. As far as tutorial, I am not aware of any tutorials in this area, but we can post a note to wtp-dev to make a public announcement.
Source Editing Components
Selection in the XML/HTML/JSP Editors
The XML (and HTML and JSP) Editor selection, which represents both the selected DOM Nodes and text selection, now allows for the selected Node to be an Attr Node (attribute). Listeners who were written to handle Element Nodes may wish to use Attr.getOwnerElement() in this case. Bear in mind that Node.getNodeType() is quicker at runtime than checking for the implementation of a particular DOM Interface.
SSE-based editors now support Semantic Highlighting via extension point.
In WTP 3.1M5, the org.eclipse.wst.sse.ui.semanticHighlighting extension point was added for adopters to contribute their own highlighting information. This extension point is used to define a "semantic highlighting" instance, declaring the content types the highlighting is valid for and the class that defines the consumable regions and preferences for the stylings.
<extension point="org.eclipse.wst.sse.ui.semanticHighlighting"> <highlighting class="com.example.highlighting.NamespaceHighlighting" target="org.eclipse.core.runtime.xml, org.eclipse.wst.xml.core.xmlsource"> </highlighting> </extension>
The class defined in the highlighting element must implement org.eclipse.wst.sse.ui.ISemanticHighlighting, and is responsible for identifying the consumable IStructuredDocumentRegions--which regions it affects. If a document region is consumable, the preference store returned by its getPreferenceStore() method is queried for styles using the keys from the get*Key() methods.
End users can enable Semantic Highlighting from the Structured Text Editors Preference page.
org.eclipse.wst.xml.xpath2.processor plug-in internal refactoring
Several classes in the PsychoPath XPath 2.0 processor have been moved to internal classes. This was done to help with future refactoring and bug fixes that may break public methods or interfaces. The main classes that are needed to execute XPath 2.0 expressions are still in the public packages. Any package with the Internal keyword is subject to change in future versions. Particularly as the W3C xpath test suite is addressed.
Note adopters will need to access the classes in the internals.types pacakge as these are brought into compliance with the specification they will be promoted to API packages.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=273848 for more information on the refactoring.
Web Services Components
Upgrade to WSDL4J 1.5.1
The WSDL editor, model, and validator have been upgraded from using WSDL4J 1.4.1 to using WSDL4J 1.5.1. If your plugin has a dependency on org.eclipse.wst.wsdl.validator.* or org.eclipse.wst.wsi.* as well as javax.wsdl, please either update your dependency on javax.wsdl to 1.5.x or please ensure your dependency on the javax.wsdl plugin is stated before your dependency on the wsdl plugins in your manifest.mf file. If your plugin has a dependency on org.eclipse.wst.wsdl.* plugins as well as javax.wsdl, please update your dependency to javax.wsdl 1.5.x. Please see the following bugs for more details: Bug 197197 Bug 252257 Bug 252258
Removal of WSDL4J 1.4.x
After the above migration, WTP no longer requires the javax.wsdl 1.4.x plugin. This has been removed from the WTP zips.
Java EE Tools Components
- Deprecated resources in WTP 3.1(M6)
- Removed resources in WTP 3.1(M6)
Removed resources in WTP 3.1(M6)
- Removed several assembly features from zip files: org.eclipse.wst, org.eclipse.jst, and their sdk counterparts, org.eclipse.wst.sdk, org.eclipse.jst.sdk. For some time, these were intended simply as convenient collections of features to help guide builds, but since mistakenly distributed in zip files, there was plenty of opportunity for confusion.
- In general, prereqing features should be minimized, but when it is required, the "lowest" feature possible should be pre-req'd. See Version_Numbering for more information.
- Probably the most common use-case would have been to simply pre-req the "wst" portion of wtp. If that was done, and if a quick fix or replacement is desired, it would be to use the features that made up wst directly. See bug 277589.
- <import feature="org.eclipse.wst" version="3.1.0" match="compatible"/> + <import feature="org.eclipse.wst.common.fproj" version="3.1.0" match="compatible"/> + <import feature="org.eclipse.wst.jsdt.feature" version="1.1.0" match="compatible"/> + <import feature="org.eclipse.wst.xml_ui.feature" version="3.1.0" match="compatible"/> + <import feature="org.eclipse.wst.web_ui.feature" version="3.1.0" match="compatible"/> + <import feature="org.eclipse.wst.server_adapters" version="3.1.0" match="compatible"/> + <import feature="org.eclipse.wst.xsl.feature" version="1.0.0" match="compatible"/>