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?
Usability/Tooling
=================
- A nice usable, and polished management console.
- 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).
- True hot deploy/undeploy (is this working? or does it need work? I
have been somewhat unsuccessful without some form of restart)
- Sniffable deploy directory. It would be nice to drop EAR/WAR/etc
in a directory and have it auto deploy, at least for development
- Eclipse-based IDE (for J2EE code generation), with a geronimo test
environment embedded in eclipse.
- IDEA plugin
- NetBeans plugin
- Start defining APIs and Interfaces that will be supported at 1.0
timeframe and going forward.
- 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.
- Good pluto or other portlet integration. Also a portlet based
management console.
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.
- 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.
- 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.
- Move to xmlbeans v2.
- Make sure tx recovery works and build a UI for reviewing problems
- True clustering with rolling deployments (i.e. deploy but don't
activate until I say I am ready).
- Performance - get performance suites to run
- Performance - once running, start looking at optimization and
enhancement for performance
Other
=====
- QA test plan
- QA test resources (people, computers)
- M4 milestone release
- nightly build generation and maintenance
- harvest good material from the wiki and add to website
- find donated access to platforms for CTS certification to build a
big compatibility matrix
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
