Geronimo Tooling Roadmap

[Sachin Patel <sp...@gmail.com>]

As we prepare moving Geronimo tooling to its new home, here is an 
initial road map that I feel are the necessary first steps in creating a 
robust and useful tooling environment for Geronimo.

(1) Build infrastructure
- Since Eclipse has not fully converted all their plugins from an 
expanded directory structures to packaged jars it is not yet a 
reasonable approach to build the tooling pieces purely with Maven since 
dependency artifacts in Maven IIUC must be jars.  So the approach I 
think that needs to be taken is that we use the integrated Eclipse build 
framework the PDE which can be invoked and run in a headless mode 
through ant.  I can probably steal some time from the Eclipse folks to 
help get the necessary build scripts set up correctly.  The PDE build 
will be able to build and package the plugins and their features.  A 
source feature can also be created that will contain all the source as 
well.  Then we can wrap the PDE build with a maven goal that can be run 
independently of the rest of the geronimo build.  This way there is no 
additional overhead for developers concerned primarily with server 
development.  So even if the decision is made to keep the source in the 
same branch, they will and should be built independently by default.

(2) Jira Geronimo component needed for Tools.  (Will need one of the 
committers help to get this created).

(3) Generate the necessary EMF based infrastructure that can can be then 
used to build additional features ,editors, views for the server 
adapter.  (In progress). EMF can be used to auto generate model code 
(similar concept to Bean's), edit, and editor code, all based on the 
deployment plan schema.  The stubbed out and default implementations of 
the generated edit and editor code can then be modified to provided user 
friendly views, editors and context menu actions for and accessing 
deployment plan data.  Once of the nice thing about EMF is that all the 
notification infrastructure is created with default implementations for 
you.  So multiple views representing the same data in different ways 
will always be in sync... For example adding a resource ref in the 
deployment plan using the deployment plan editor will refresh and update 
a tree view in a completely separate window/view even workbench showing 
the list of resource refs.  EMF also provides a concept of a change 
recorder where if multiple areas of the model have changed you can 
receive a change description with what changed, containing both old and 
new values.

(4) Auto generation of deployment plan files at project creation.  For 
example, if the the user chooses to create a web project and that web 
project is target to be deployed on Geronimo, then the geronimo-web.xml 
file should automatically be created.  The user can then double click 
the geronimo-web.xml file and the deployment plan editor will appear. 
(Currently it is being created prior to deploy time).

(5) Deployment via JSR-88 (Done).

(6) Extensions to launch admin and debug console.

(7) Remote deployment.  Should be able to deploy applications running a 
remote server.

(8) JSR-75 Annotations for deployment plans.

Once  these necessary initial steps are done, (1-6)  I think the sky is 
the limit.  Once the friendly views and editors are created, we can the 
focus on usability features helping to provide values for deployment 
plan elements.  For example, we could have a browse button on certain 
entries in the deployment plan that would access the server for list of 
existing data sources, gbeans, etc..basically anything that can be found 
through JMX.  So rather then modifying entries by hand which is very 
error prone, values could in situations be provided for you.  I think 
alot of work can be done in the annotation space as well, creating 
processors that can run as invoked as part of the java compiler that 
will update the deployment plans.  Alot of this infrastructure to be 
able to do this will be addressed by upcoming JSRs. 

Let me know your thoughts and or additional ideas and we can start 
prioritizing them.

Thanks.

Sachin.