New Help for Old Friends

This page to to collect miscelleneous notes and pointers to changes coming up in the WTP 1.5 release. Its purpose it to be a central "jump off" point for those adopters of WTP 1.0, that are moving to WTP 1.5. Most of this information may be already contained in various mailing lists and bugzilla's, but ... we thought it best if there as a list of sorts to get people started.

Adopters: if you run into trouble or notice things that are not covered here, please let us know (wtp-dev@eclilpse.org is a good place). This will not only help us keep this list 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 API's, migration instructions, etc., in the future. It isn't 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 lesson I've learned recently is that some don't adopt every version ... some early adopters are going from 0.7 directly to 1.5, for example. Unfortunately, that was so long ago for us, that we can't really document 0.7 to 1.5 migration .. this document will focus on 1.0 to 1.5 migration ... and, hopefully, will still be here for anyone migrating from 1.0 to 2.0 :)

Note: as these notes develop and grow in number, they may occasionally be re-organized into categories, etc.

Validation Framework Enhancements

The Validation Framework has been reworked to improve the overall performance of client validators that are built using the framework. The rework has been completed to a point where it is ready for extenders of the framework to consume it. All rework done so far has been released to this weeks I build.

The rework had been in both UI and Non UI areas. The UI changes are mainly to simplify usability and give more granular control of when client validators are run at project level and global level. The Non UI changes is mainly the addition of Job support into the framework to run them in the background thread. Additionally there are also some Feature Enhancements done.

We would like all validators in WTP to use the Job support and convert all the existing validators to the new Job api as this encourages all adopters on top of WTP to use this support. Please get back to us it you need help moving to the new api or have any feedback about the implementation.

The details of these changes so far can be found at http://www.eclipse.org/webtools/wst/components/validation/ValidationFrameworkRework.html.

Thanks,

Regards, Vijay

Tabbed Property Pages

The org.eclipse.wst.common.ui.properties plugin (for tabbed properties) has been moved to the eclipse base M5.

For those clients using this plugin, please migrate to the new plugin org.eclipse.ui.views.properties.tabbed. The migration document, courtesy of Anthony, can be found in bug 109878.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=109878

The plan is for clients to migrate before WTP M6. (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=125745). The WST plugin will be marked deprecated for now, and will be removed after M6..

Regards, Keith Chong

WTP Project Explorer migrated to Eclipse Common Navigator Framework

Extended Team,

First, let me remind you that the Eclipse Common Navigator framework remains a work in progress and with that said, the resulting explorer in WTP based on the eclipse framework is also a work in progress. On the whole, the functionality of WTP 1.0.1 has basically been restored so I am at a good point to release to an integration build to start allowing adopters to react. The changes for extenders should not be as drastic as they might be fearing and there is a logical replacement for everything. The eclipse framework extension point schema documentation is really quite full and up to date so my advice is to go there, read it, become familiar with it, and use it as a reference. There are some key things to note about the migration process:

There is a new plugin which defines the WTP extension to the eclipse common navigator: org.eclipse.wst.common.explorer. This is done so that JST is not required.

Essentially, the new framework paradigm can be summed as you bind navigator contents to navigator viewers. So you can add any existing content extensions to your viewer by just adding a binding to the content extensions id.

You will need to remove dependencies to the 3 old navigator plugins: org.eclipse.jst.common.navigator.java org.eclipse.wst.common.navigator.views org.eclipse.wst.common.navigator.workbench

These plugins will be deprecated and removed in WTP 1.5 M6. The new plugins are: org.eclipse.ui.navigator org.eclipse.ui.navigator.resources

and  hopefully also one from JDT, (the java content extension has not been implement yet!) 

The extension point org.eclipse.wst.common.navigator.workbench.commonWizard is replaced by commonWizard under org.eclipse.ui.navigator.navigatorContent

The WTP viewer ID = org.eclipse.wst.navigator.ui.WTPWorkingSetCommonNavigator was replaced by org.eclipse.wst.common.explorer.CommonProjectExplorer

Enablement expressions converted to org.eclipse.core.expressions. "objectClass name=" goes to "instanceof value=" especially in common wizard extensions. For example: <test property="org.eclipse.core.resources.projectNature"

   value="org.eclipse.wst.common.modulecore.ModuleCoreNature"/> 

You can also test facet enablement by using <instanceof value="org.eclipse.core.resources.IProject"/>

                  <test property="org.eclipse.wst.common.project.facet.core.projectFacet" 
                                value="jst.ejb"/> 

You must switch your dynamic adapter factories to reference this new viewer ID to display content properly: org.eclipse.wst.common.explorer.CommonProjectExplorer.

The j2ee project creation/import/export wizard ids were changed to be the name of the wizard class for consistency as API.

Once again, the java content is also not ready from base eclipse JDT. For now, make use of the java perspective in tandem.

Also, you will notice we have gotten rid of the groupings. This is a preliminary decision as many users did not find them useful. We may add back an option later when we have the working set support from eclipse.

This is targetted for the WTP 1.5 I build for Thursday February 16th. Please plan accordingly. If you have any questions, caveats, and concerns, feel free to contact me.

Thanks,

John Lanuti

XML, HTML, CSS, DTD, JavaScript and JSP Partitions

IDocuments can be divided into partitions, and those partitions associated with various things. In Version 1.0, these partition IDs were marked as "provisional", simply because we ran out of time. In 1.5, they will be moved to "API packages" and undergo a few slight name changes for consistency. While the deprecated versions will be left in place, we encourage everyone to migrate so we can clean up the code, if no adopter appears to be using them.

[Phil Avery]

No-Dots-in-content-type-IDs rule now enforced

This isn't really a WTP change, but might effect WTP clients, since many adopters have their own content types, for special editor configurations. There is a change in behavior in how content types are process in the platform eclipse. Its still works "according to spec", but in the past, the spec wasn't really enforced ... it now is, so might appear as a change in behavior. See bug 139491.

If if you used a content type ID with 'dots' in it, such as "xml.fragement" you will want to change to "meet spec", and use an id without dots or spaces, such as "xmlfragment". Your plugin's ID is pre-pended to the content type ID (in this later case), so there is no risk of name collision.

Small Changes to IDOMDocument interface

Due to the issues documented in

bugzilla 140681 and bugzilla 145289

we in SSE/XML framework changed our IDOMDocument interface

IDOMDocument no longer implements org.w3c.dom.ranges.DocumentRange, and org.w3c.dom.traversal.DocumentTraversal

The problem, in brief, was that some people were finding that they might have to "require xerces" for Sun 1.4.2 JRE's, when they might not even use DocumentRange or DocumentTraversal, which is bad for many reasons. (Now, it turns out, that with subsequent fixes, to appear in WTP RC5, no one should have to require xerces, due to us, but we did not know that for a while and since this change is an excellent change anyway, for many reasons, we'll leave as it).

Possible Implications for Adopters:

If you previously had statements such as

if (doc instanceof IDOMDocument) {
    ranges = ((IDOMDocument)doc).createRanges();
}

you will need to change to

if (doc instanceof DocumentRange) {
    ranges = ((DocumentRange) doc).createRanges();
}

Similar for "treeWaker" method of DocumentTraversal.

These are, it turns out, the normal, recommended "DOM programming" ways of doing these functions anyway.

We *will* continue to implement these methods on our implementation, just not contract to that on our "souce oriented dom" interfaces. As we make these official API's, in WTP 2.0, we want our interfaces to be "purely" ours, and everone to use standard DOM interfaces whereever possible.

DataModelWizard subclasses run in non UI thread now

There is a small change to the DataModelWizard class. In 0.7 the default was to execute the operation in the UI thread, now the default is to spawn a new thread. If you have a DataModelWizard subclass that must execute in the UI thread, then you need to override runForked() to return false. Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=131861 for more details.

Binary Modules in EAR Projects

In 1.5 the J2EE team added support for EAR projects to contain binary copies of the J2EE modules they contain instead of using separate projects. Unfortunately, this information was not pushed up through server tools so there was no way for servers tools API users or server adapters to know about the binary modules; they couldn't be published or used by downstream components. To support this in 1.5.1, there will be two API additions in wst.server:

org.eclipse.wst.server.core.util.ProjectModuleFactoryDelegate

  IModule[] createModules(IProject)

 This method will allow module providers (components that tell server tools about modules that can be run on a server) to support multiple modules per project.

org.eclipse.wst.server.core.ServerUtil

  IModule[] getModules()

 This method allows downstream API users to access modules when there are more than one per project.

This change is binary compatible and will not affect existing server adapters. The only components that need to react are the jst.j2ee team (to feed in the new module information) and downstream server tools API users that want to take advantage of the new J2EE project structure.

Please see bug 151696 for further information.