Geronimo Eclipse Plugin - Development Roadmap

M2 Build Improvements

• Need to add support for qualified builds. JIRA 0000
• Scripts to update site.xml and publish distributions to the update site. JIRA 0000

Plugin Features

• Fully support "Run resources from workspace" JIRA 0000
• Export Geronimo Plugin wizard JIRA 0000
• Remove all ties to the WTP Generic Server Framework. JIRA 0000
• Full set of deployment plan editors JIRA 0000
• Custom source view for deployment plan that provide a fully synchronized non qualified view of a deployment plan. JIRA 0000
• Run schema conversion directly from runtime to reduce footprint JIRA 0000
• Add the Geronimo shared library as an optional part of the runtime classpath container. JIRA 0000

WTP Features

The following are requirements to WTP for function that need to be implemented to improve the Geronimo plugin.

• Improve installable runtime support to use archives directly BUGZILLA 0000

Geronimo Runtime Requirements

The following are requirements to Geronimo itself in order to implement many of the features listed above.

Improve support for tooling integration.

Problem

In large enterprise deployments, a workspace consisting of hundreds of projects, the copying of a set of resources or generating a new ear to test every change leads to an enormous impact on performance resulting in a poor user experience.

Solution Abstract

In order to improve integration with tooling environments, Geronimo needs to improve its flexibility with where and how application contents are located at time of deployment. An optimal development environment consists of an environment in which the deployment processing time is kept to a minimum and users can make code modifications and test them with little or no overhead after every save and/or publish. An effective way to achieve this is to reduce resource copying and be able to run an entire J2EE application from within any given IDE's project structure. The geronimo runtime needs to be much more adaptable in locating application contents and not restrict itself to an ear structure as defined by the J2EE specification. In this proposal, we will use the Eclipse WTP J2EE project structure as an example showcasing where different types of resources can reside. Eclipse is only being used as an example, and the eventual solution should not be specific to Eclipse but flexible enough to be applied to any IDE. However a common solution may not be possible due to the fact different IDEs have completely different project structures. Thus I think the geronimo runtime must tightly support IDE integration and have the necessary plug points to support multiple IDEs.

In Geronimo, resources needed to be located at two different phases in the deployment process. Once when a module is being distributed and its configuration is being generated. The second is when the generated configuration is started. For the latter, a plug-gable solution already exists in that a custom configuration store can be used that provides a IDE aware implementation of the ConfigurationStore.resolve(Artifact artifact, String module, String path) method. What is lacking is a plug-gable solution for the distribution phase when the application is being processed by each of the builders. So each of these builders cannot make assumptions about where resources it needs to process are located. For example, the EARConfigBuilder cannot assume that the ear's modules are nested with the root of the ear.

Example Support Scenario

1. Allow modules to reside outside of an ear, must not assume a J2EE structure with each j2ee module located directly inside the root of the ear.
2. Any jar references must be resolvable and must not assume that is it a packaged archive, this goes for web library entries, utility jars, and manifest entries.
   1. A referenced jar could be a project, in which case that jar root would be the output folder of a project in the workspace, or could be a referenced jar anywhere on the filesystem
3. The location of java classes in a module may not reside at the root of the module where the module meta-data resides, as shown in the diagram above.

Solution Proposal