Geronimo Eclipse Plugin - Development Roadmap

M2 Build Improvements

• Need to add support for qualified builds. GERONIMODEVTOOLS-65
• Scripts to update site.xml and publish distributions to the update site.

Plugin Features

• Fully support "Run resources from workspace"
• Export Geronimo Plugin wizard
• Remove all ties to the WTP Generic Server Framework. GERONIMODEVTOOLS-52
• Full set of deployment plan editors
• Custom source view for deployment plan that provide a fully synchronized non qualified view of a deployment plan.
• Run schema conversion directly from runtime to reduce footprint
• Add the Geronimo shared library as an optional part of the runtime classpath container.
• Deploy to shared library
• Support profiling mode
• Provide custom sourcePathComputers to provide source lookups to Geronimo source
• Support for non-plugin archives for installable runtimes GERONIMODEVTOOLS-93
• Installer
• Investigate Geronimo Jars referenced outside of runtime bundles

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 AVAILABLE IN WTP 1.5.1

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. This proposal address the issue of developing and deploying a large set of projects.

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. However this by itself has extreme limitations. 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

Below is an example of a directory structure layout of a J2EE application that consists of 1 ear project, 1 web project, and a single web library project. The first thing you will notice is that the projects are flattened and the web project is not nested within the ear. Take a look at the diagram notes for the structure of the rest of the application.

These are the primary cases which cover most scenarios, there may be more.

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

?