geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <sbaill...@apache.org>
Subject Re: Summary checkpoint - Roadmap / Things-to-do
Date Tue, 14 Jun 2005 12:28:20 GMT
Geir Magnusson Jr. wrote:
> Here is a summary of what we saw on the list, and some other things  
> thrown in.  The order is arbitrary, and we should discuss how to  
> prioritize.  Of course, if something grabs your fancy, grab it.
> 
> Also, this is just a checkpoint - lets add more and clean this up,  
> prioritize and then put on the website?

It would be nice to have at least an idea of what you think about the 
roadmap ? What do you expect from the 1.0 ? A certified J2EE container 
with plumbing or a certified j2ee container with fancy consoles and 
features ? What do you expect from the M4 ?



I'm assuming the 1.0 release to be the bare minimal so that developpers 
can start to develop on it seriously. Since the dev cycle is more on the 
6-month range on J2EE projects, this gives time to do bug-fixes releases 
and enhance with priority 2 and 3 features during that time once the 1.0 
release is done.

I'm setting the following priorities, for the sake of starting with 
something, but this needs more iteration on the definition of it:

P1: Cannot have a 1.0 release without this feature
P2: Nice to have. Can wait 1.0+ release
P3: Very nice to have, can wait a 1.1+ release.


> Usability/Tooling
> =================
> 
> - A nice usable, and polished management console.

P3

P2: would be for a minimal UI.

A lot of low-end j2ee apps are deployed without ever using the admin ui, 
this is mostly a fire and forget deployment, so this is why I'm putting 
that as a non-P1

> - A GUI configuration tool that allows you to add/remove components,  
> where the result is a set of plans with your custom configuration.  (No 
> more XML hacking for the newbies out there).

P2

> - True hot deploy/undeploy (is this working? or does it need work?  I  
> have been somewhat unsuccessful without some form of restart)

P1

> - Sniffable deploy directory.  It would be nice to drop EAR/WAR/etc  in 
> a directory and have it auto deploy, at least for development

P1

> - Eclipse-based IDE (for J2EE code generation), with a geronimo test  
> environment embedded in eclipse.

P3

> - IDEA plugin

P3

> - NetBeans plugin

P3

> - Start defining APIs and Interfaces that will be supported at 1.0  
> timeframe and going forward.

P1

> - Come up with a reasonable solution to the desire to set ports, pool  
> sizes, etc when starting the server.  To me this definitely does not  
> involve editing the contents of the original deployment plans or the  
> compiled configurations but some entirely separate solution such as a  
> configurable property database gbean.

P1

> - Good pluto or other portlet integration.  Also a portlet based  
> management console.

P3, but this has to be thought from the ground up as it could impact the 
UI console from an architecture POV. Who knows, the UI console could 
well be a pluto-based portal.

> Technical Features
> ==================
> 
> - Complete Jeremy's packaging and assembly plugins and use them as  much 
> as possible in the build.  I think this will make how geronimo  is 
> intended to fit together a lot clearer and make the build make  more sense.

Could you please clarify from a feature point of view what it brings ?

> - Examine and stabilize the interfaces between geronimo modules (also  
> between geronimo/openejb etc).  Ideally we could stabilize these to  the 
> extent that no iterface changes would be necessary until geronimo 2.

P2 (but it does no go as it does not involves breaking configuration for 
every release)

> - Review the contents of each module to make sure it makes sense.   For 
> instance, I think that openejb core has at least 3 modules inside  it.  
> I'm also not quite sure about the distribution of code between  the 
> connector and transaction modules.

P1

> - Move to xmlbeans v2.

P2. What is the move justification ? What does it brings ?

> - Make sure tx recovery works and build a UI for reviewing problems

P2. tx is of critical use in apps but I doubt anyone will use Geronimo 
for critical apps for a while. So this gives a bit of time to consolidate.

> - True clustering with rolling deployments (i.e. deploy but don't  
> activate until I say I am ready).

P2. Same as above.

> - Performance - get performance suites to run

P2+ .

> - Performance - once running, start looking at optimization and  
> enhancement for performance

P2+

> Other
> =====
> 
> - QA test plan

P1+

> - QA test resources (people, computers)

P1+. Can you clarify exactly what is your plan on this ? Does that mean 
that IBM plans to invest for some QA resources for Geronimo ?

> - M4 milestone release

P1E999

> - nightly build generation and maintenance

P1E9999999

> - harvest good material from the wiki and add to website

Uh ? Is that necessary ? What kind of information do you want to harvest 
? IMHO you should not duplicate the source of information.

The current problem with the website is that it is stalled information. 
It does not show real activity (it has been mentioned numerous times 
already) while there is a tremendous effort going on...but no one knows 
on what. This is the problem IMHI. We should avoid adding quantitative 
information, but qualitative and avoid if possible multiple sources.

> - find donated access to platforms for CTS certification to build a  big 
> compatibility matrix

External people cannot have any info on that. correct ?


I may add:

* Add small samples demonstrating various configuration cases to help 
jumpstarting news users:
  - MDB
  - SLSB / SFSB
  - EB (simple one and different cases with relationships 1:1, 1:N, .., 
cascaded or not)
  - JAAS
  - TX

  P1

* Add migration HOW-TOs from known app. servers (try to see if we could 
use a migration tool ?)
P2


My 0.02 cents :)


Mime
View raw message