I'd add (in no particular order, and not necessarily all for 1.0):
- Provide database support for at least Oracle, SQL Server, PostgreSQL,
MySQL, Derby, DB2, Sybase
- Implement more DBSyntaxFactory/EJBQLCompilerFactory alternatives, or
list the database products that the Derby implementation works well
for.
- Implement the ExceptionSorterClass for various products
- Ensure the Oracle XA drivers work
- Create a CMP test suite that can be run on a database product to
ensure that everything "works"
- Implement CMP/CMR load groups, to control what fields/relationships
are loaded when a finder is executed
- Coerce all use of threads into defined thread pools. Separate the
pools into "short-term" (normal pooling) and "long-term" (consumer won't
be letting this thread go but at least we can track it) pools
- Tomcat
- Jetty
- ActiveMQ
- CORBA
- Other?
- Provide a tool to generate web services WSDL (and if necessary JAX-RPC
mappings) from Session Bean Service Endpoint Interfaces. (Sun has
wscompile, but I'm not sure we have a similar tool -- maybe we already
do.)
- User documentation
- Working Pet Store (procedures + deployment plans?)
- Remote deployment and management (that is, developer on a different
machine than server and not FTPing stuff back and forth)
- Faster install routine (current installer deploys all plans one at a
time and takes a while)
- Add self-signed certificate generation to the install routine, so every
installation on earth doesn't default to the same cert
- Provide a graceful solution to the Tomcat/Jetty problem (how does a
user pick one, can both be run at the same time, what's certified, etc.)
- Eliminate any remaining memory leaks, if at all possible
- Ensure we allow 100+ redeployments of a non-trivial EAR
(including JSP compilation) without OOM error
- Provide JSR-88 config beans for all deployment descriptors
- Provide a convenient way to redeploy a single JSP during development
without redeploying the entire app
- Ship a "clean" server configuration (no test or extra database pools,
JMS destinations, or applications, unless the user asked for demos to be
installed)
- Provide Ant task(s) for deployment
Aaron
On Mon, 13 Jun 2005, 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?
>
>
> 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]
>
>
>
