geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Summary checkpoint - Roadmap / Things-to-do
Date Tue, 14 Jun 2005 12:49:36 GMT

On Jun 14, 2005, at 8:28 AM, Stephane Bailliez wrote:

> 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 ?

M4 : I'd like to do that ASAP :)

1.0?  I think that it should be certified of course to ensure that  
the J2EE functionality is there, but also some bit of "fit and  
finish" for basic tooling and usability.
>
>
>
> 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.

Ye - but we want to make that bare minimum usable :)

>
> 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.
>

Ok - I'll recapture this and Aaron's feedback in another checkpoint  
summary.  Anyone else feel free to comment w/ P1, P2, P3 and we can  
collect...


My comments inline

>
>
>> 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 ?

I'll let the contributor of that one comment...

>
>
>> - 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 ?

I think we have to do a few unnatural acts to work w/ xmlbeansV1.  
IIRC V1 defines a few classes like QName that cause some havoc...?
>
>
>> - 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 ?


Not only IBM.  Anyone that wants to help -

For example, we could use systems w/ different OSs, JVMs, DBs that  
are used for continuous integration testing.

>
>
>> - 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.

Well, lots of the wiki is out of date.  Cruft tends to accumulate.   
There are things like "how to build" which are things that every new  
developer wants to know, and we can have that available on the  
website (or linked to the wiki from the website) as the website is  
the first place people come to.

>
> 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.

Sorta.  The website has just been re-done, and there should be no  
more stall.  If you have a suggestion for the site, throw it out and  
we'll do it ASAP if reasonable, or - as always - send a patch.

>
>
>> - find donated access to platforms for CTS certification to build  
>> a  big compatibility matrix
>>
>
> External people cannot have any info on that. correct ?

Right - this would be for the use of the peeps doing cert, but the  
matrix of where we certified is certainly public knowledge.

>
>
> 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
>

yes!

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

yes.  And yes, having tools would be great.


>
> My 0.02 cents :)
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message