geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Summary checkpoint - Roadmap / Things-to-do
Date Tue, 14 Jun 2005 00:25:14 GMT
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
> geirm@apache.org
> 
> 
> 

Mime
View raw message