The flexible project support in WTP has lead to creation of new api and deprecation of exisitng api. Consumers of existing api need to move on to the new api to get their functionality working. Even though the old api exists and is deprected, if it is still used the functionality will be broken as those deprecated api are not being used internally anymore. The major api usage shift is in J2EE Nature Runtime classes and J2EE Edit models. The following document provides an overview of the api changes and how they need to be used to get the old desired functionality using the new api.

This document is an ongoing document and as and when new api are available for the flexible project support and old api deprecated this document will be updated.

Api and Usage

Using the Flexible project layout a single ProjectComponent that is the top level entity can be associated to multiple WorkbenchComponents. Each WorkbenchComponent can be associated to multiple ComponentResources. Each WorkbenchComponent can be associated with multiple DependentComponents. To access the structural model of these objects you need to use the api available in the ModuleCore class which in the past the api on *NatureRuntime classes were used. To access the the WorkbenchComponent content metamodel the api in the *ArtifactEdit classes which in the past was through accessing *EditModel classes.

ModuleCore

ModuleCore hides the management of accessing EditModels ({@see org.eclipse.wst.common.modulecore.ModuleStructuralModel}) correctly. Each project has exactly one ({@see org.eclipse.wst.common.modulecore.ModuleStructuralModel}) for read and exactly one for write. Each of these is shared among all clients and reference counted as necessary. Clients should use ModuleCore when working with the WTP Modules Strcutrual Model. The Api on ModuleCore class has well documented with JavaDoc and to get feel about the usage of these api, check for the references of the api's.

Each ModuleCore edit facade is designed to manage the EditModel lifecycle for clients. However, while each ModuleCore is designed to be passed around as needed, clients must enforce the ModuleCore lifecycle. The most common method of acquiring a ModuleCore edit facade is to use {@see #getModuleCoreForRead(IProject)} or {@see #getModuleCoreForWrite(IProject)}.

When clients have concluded their use of their ModuleCore instance adapter , clients must call {@see #dispose()}.

ArtifactEdit

Provides a Facade pattern for accessing Module Content Metamodels for WorkbenchComponents. ArtifactEdit hides the management of accessing edit models ({@see ArtifactEditModel}) correctly. Each project may have multiple ({@see ArtifactEditModel})s depending on the number of modules contained by the project. Clients should use ArtifactEdit or an appropriate subclass when working with the content models of WTP modules.

Each ArtifactEdit facade is designed to manage the EditModel lifecycle for clients. However, while each ArtifactEdit is designed to be passed around as needed, clients must enforce the ArtifactEdit lifecycle. The most common method of acquiring a ArtifactEdit instance facade is to use {@see #getArtifactEditForRead(WorkbenchComponent)}; or {@see #getArtifactEditForWrite(WorkbenchComponent)}. When clients have concluded their use of the instance, clients must call {@see #dispose()}

The current api that is available on each j2ee artifact edit is listed below. More api on each j2ee artifact edit will exposed out subsequently as needed by code that is consuming the old api through natures and edit models.

WebArtifactEdit

The WebArtifactEdit class provides the api that were available on J2EEWebNatureRuntime and WebEditModel class. The J2EEWebNatureRuntime and WebEditModel classes and all the api in these classes will be deprecated. Any consumers of the api in J2EEWebNatureRuntime have to migrate their code to use the api on WebArtifactEdit. The list of old and corresponding new api are listed below with examples.

EARArtifactEdit

The EARArtifactEdit class provides the api that were available on EARNatureRuntime and EAREditModel classes. The EARNatureRuntime and EAREditModel classes and all the api in these classes will be deprecated. Any consumers of the api in EARNatureRuntime and EAREditModel have to migrate their code to use the api on EARArtifactEdit. The list of old and corresponding new api are listed below with examples.

AppClientArtifactEdit

The AppClientArtifactEdit class provides the api that were available on ApplicationClientNatureRuntime and AppClientEditModel classes. The ApplicationClientNatureRuntime and ApplClientEditModel classes and all the api in these classes will be deprecated. Any consumers of the api in ApplicationClientNatureRuntime and AppClientEditModel have to migrate their code to use the api on AppClientArtifactEdit. The list of old and corresponding new api are listed below with examples.

EJBArtifactEdit

The EJBArtifactEdit class provides the api that were available on EJBNatureRuntime and EJBEditModel classes. The EJBNatureRuntime and EJBEditModel classes and all the api in these classes will be deprecated. Any consumers of the api in the EJBNatureRuntime or EJBEditModel classes have to migrate their code to use the EJBArtifactEdit. The list of old and corresponding new api are listed below