The following are requirements to WTP for function that need to be implemented to improve the Geronimo plugin.
The following are requirements to Geronimo itself in order to implement many of the features listed above.
Problem
In large enterprise deployments, a workspace consisting of hundreds of projects, generating a new ear(s) 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
Solution Proposal