Difference between revisions of "New Help for Old Friends"
|Line 88:||Line 88:|
Revision as of 13:12, 2 May 2006
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 (email@example.com 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.
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.
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
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"
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.
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.
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.