|Home > Apache Geronimo v1.1 > Documentation > Apache Geronimo v1.1 - Developer's Guide > Geronimo Eclipse Plugin - Development Roadmap|
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.
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.
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.