Refreshed Content

Recently we have had two very productive meetings with the eclipse platform team, in understanding some of the proposals for 3.2 that give WTP more options in regards to flexible workspaces/projects. During these meetings 4 proposals were discussed that tackle different aspects of "flexible workspaces" Much of the existing flexible project internal api is an implementation that satisfies many of the requirements declared last year. Many of these scenarios should be solved at the platform level, and our current WTP api has a few serious restrictions that forces us to re-evaluate our direction.

Two main issues exist with our current support:

• The IVirtualResource layer forces all clients to adopt this api(causing possible perfomance issues), and needing to recreate core functionality supplied by the platform (Resource Listeners/Deltas, Marker support etc).

• Multiple components per project can't be supported by the platform/jdt teams, as this is not seen as an evolutionary change. Too many existing clients would need to react which is not feasable., and sharing a single classpath across multiple modules is seen as a fatal flaw.

Here are the four proposals:

• IResource API providing a facility for service providers to add an abstract file system layer. Behind the scenes, an extension point will allow plugins to install "scheme handlers" that provide implementations of an abstract file system API. This file system API is similar to java.io.File, while fixing some of its obvious defects (added progress monitors, exceptions with descriptive messages, the ability to fetch and store multiple attributes of a file in one native call, etc). This allows plugins to provide custom file system implementations that IResources can be stored in.

• Arbitrary depth resource linking support. Currently, resource linking is only supported from the root of the project, this would allow linking from arbitrary depth - Note: the target of the link doesn't have a restriction in or out of the workspace.

• Non-java "Source" folders(Expanded detail) Similar to the jdt source folders, "web" folders could build or assemble web(or other) content into an output or "assembled" location(hidden from the user). Folders could be specified at project creation, or through project property sheets. (similar to the jdt source folder view)

  

  These folders will also have the ability for "filters", and this will be especially useful for overlapping cases with java source folders. In the simplest case, java content, and web content would have seperate folders, and seperate output paths, it should be possible to designate both source folders and web folders on the same physical root, and using filters(*.java,*.class), could specify an output seperate from the java content. The component metadata file (.wtpmodules) will continue to track these folders, as well as java folders for purposes of inclusion into the deployable archive. (*.war, *.jar).

  The assembly of these folders could be done with a builder, or (better yet) could be deferred to a publish task, where the server may choose to leave the source as is if no assembly is required. Also, something to consider, the server may want to assemble (outside) the workspace, in this case, the designated output location could be used as a relative location from a module root - suggestions welcome....

• Project mapping using exclusion filters.(Expanded detail) Currently java source folders have the ability to define filters, this concept could be added at the project level, allowing multiple projects to "share" a common root with mutually exclusive filtering rules (no overlapping content). The Team platform will be required to respect the filters while checking in/out content, Additionally, the team platform should support "team project sets" that could handle multiple project checkin/out.

The outcome of the meetings essentially pruned out one of the proposals (Creating an AFS under the IResource layer ). We removed the consideration of the AFS proposal because the affect of making the IResource api represent the "logical" runtime view for all clients would ultimately confuse the user by not showing the physical layout on disk.

Here's a few scenarios that demonstrate the differences between the current WTP support, and the new proposals.

Scenario 1) J2EE recommended structure:

Figure 1: The J2EE recommended build layout

Using the above scenario, the following will first demonstrate support using the current solution, then followup using the alternative proposals

• Currently, the entire structure rooted with myproject would be imported into a single java project with separate virtual components defined, containing lists of "VirtualResources". The component builder assembles the virtual resources into a "deployable" runtime structure (essentially copying content to a hidden output location). All clients must use the IVirtualResource api to understand the "virtual" runtime location of each resource. The server runtimes can use this output location on disk. The components(each having a separate java output folder) share the same project classpath. The component references model helps gather the dependent classpath entries, and locate dependent module artifacts. The Team story is clean, because the entire project is contained with a single project.

• Alternatively, with the new proposals, separate projects could be mapped for each module using similar or alternate folder roots. Filters would be applied assuring no overlap. Each module would have full project support including a separate classpath. The projects with the root folders are shown below:

  Project1: myapp1(filtering myapp1-ejb,myapp1-war)

  Project2: myapp1-ejb

  Project3: myapp1-war

  Project4: comp1

  Project5: myproject(filtering apps)

  Java source folders would be added for the "src" folders for each module(output pointing to the "build" folders) Non-java (web) folders would be setup for myapp1-war\web with an output pointing to "build" folder. The server runtimes would use the "assembled" folder contents. The component references model would continue to gather the dependent classpath entries(now on separate projects), and locate dependent module artifacts. IResource links could be used to "share" content from various locations, adding another layer of flexibility. Any client tools (editing source content) with dependencies on the "runtime structure" will need to adapt to a flexible source structure Team support would need to consider "Team project sets" that would make it possible to checkin multiple projects as a single unit.

Scenario 2) Maven recommended structure:

The following layout is recommended by the Apache Maven project:

MavenProj1/src/webapp--------------Source web content(web.xml, images etc....)
MavenProj1/src/java----------------Source java
MavenProj1/src/test----------------Unit test source code.
MavenProj1/target/-----------------Target directory contains the final JARs that are generated.
MavenProj1/target/classes----------The target/classes directory contains all compiled classes.
MavenProj1/target/test-classes-----Contains compiled unit test classes.

Using the above scenario, we will again demonstrate support using the current solution, then followup using the alternative proposals

• Currently, the entire structure rooted with MavenProj1/ would be imported into a single java project with a component, containing lists of "VirtualResources". The .wtpmodules file will need to be edited for the entries: /src/webapp and /src/java, with a runtime output of "/" and "/WEB-INF/classes". An additional java folder will need to be created for (MavenProj1/src/test). The component builder assembles the virtual resources into a "deployable" runtime structure (essentially copying content to a hidden output location). All clients must use the IVirtualResource api to understand the "virtual" runtime location of each resource. The server runtimes can use this output location on disk. The Team story is clean, because the entire project is contained with a single project.

• Alternatively, the seperate source folders can be mapped using both java(MavenProj1/src/java -> MavenProj1/target/classes) and web folders (MavenProj1/src/webapp -> MavenProj1/target/). The test folders can also be mapped using a java source folder, but will not be included in the publish task because it will not be included in the .wtpmodules folder definitions.

  The server runtimes could use the "assembled" folder contents. IResource links could be used to "share" content from various locations, adding another layer of flexibility. Any client tools(editing source content) with dependencies on the "runtime structure" will need to adapt to a flexible source structure The Team story is clean, because the entire project is contained with a single project.

Scenario 3) Project sharing scenario:

It should be possible to share resources across projects. Consider the following layout

EJBProject1/
EJBProject1/src/
EJBProject1/src/META-INF/ejb.xml

ShareableUtils/images/
ShareableUtils/templates/
ShareableUtils/src/

EJBProject1 needs the contents of ShareableUtils/images/, and ShareableUtils/templates, but with alternative folder names (img/, misc/) rooted at EJBProject1/src/.

Using the above scenario, we will again demonstrate using both the present support, and alternatives.

• Currently, both structures rooted with EJBProject1/ and ShareableUtils/ would be imported into a single java project with separate virtual components defined. The component builder assembles the seperate virtual resources into a "deployable" runtime structure (essentially copying content to the proper output location). The dependency model currently doesn't support this scenario. The component dependencies can only be created on an entire component, and additional naming flexiblity is not supported. For instance, the contents of ShareableUtils, could be mapped to EJBProject1/src, but without the ability of renaming the folders. Also, the ShareableUtils component contains src that isn't needed in this project, and furthur contaminates the shared classpath. All clients must use the IVirtualResource api to understand the "virtual" runtime location of each resource. The server runtimes can use this output location on disk. The components(each having a separate java output folder) share the same project classpath. The Team story is clean, because the entire project is contained with a single project.

• Alternatively, with the new proposal, separate projects could be mapped for each module using the two folder roots (EJBProject1, ShareableUtils). Each module would have full project support including a separate classpath. The projects with the root folders are shown below:

  Project1: EJBProject1

  Project2: ShareableUtils

  Java source folders would be added for the "src" folders for each module(EJBProject1/src/, ShareableUtils/src/) Non-java (web) folders would be setup for EJBProject1/, with a filter for the /src folder with an output pointing to "assembled" folder. Rather than using component dependencies, Resource links could be used to map the images/ and templates/ folder into the EJB Project. Alternative folder names can be created, and the unwanted java files of this project are not included in the classpath. The server runtimes could use the "assembled" folder contents. Any client tools with dependencies on the "runtime structure" will need to adapt to a flexible source structure

There are many more scenarios I could cover, but this gives a good idea of the differences each proposal would make. A feature grid located here, provides additional details concerning core eclipse features that are expected for 1st class eclipse integration.

Keep in mind these are 3.2 timeframe decisions, and we will continue our current "internal" api support through 1.0 release. But, we want to resolve these issues soon, and knowing our current direction today will help WTP components/clients plan for this support, and start defining a layer of api that WTP will support indefinitely. We also are leaning toward simplicity in our supported api, and would like to leverage any existing api contributed from the platform.

Thanks - Please send me your comments by September 27th, we will be closing on these decisions soon.

Chuck Bridgham - WTP J2EE component lead