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.

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

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.

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).

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.