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