geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Summary checkpoint - Roadmap / Things-to-do
Date Wed, 15 Jun 2005 00:48:16 GMT
> 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 hoping that we can move at a much faster pace then every 6  
months.  I personally would like to see a release every 6-8 weeks  
with at least one big new feature.  We have a lot of features to add  
to it seem reasonable to me that we can focus on getting something  
big to the users on a regular basis.

Immedately
----------

> - M4 milestone release

> - nightly build generation and maintenance

P1
-----
* Finish the debug console
We should be able to start and stop services, set properties and  
invoke via the kernel interface.  This shouldn't take more then a day  
to finish.  Maybe someone with some GUI skill could whip up a new  
layout for it, as it is a bit ugly.

* reference docs
This is not really user docs.  It is just a list of every  
configuration option and what it does.

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

>  - Provide a convenient way to redeploy a single JSP during  
> development
> without redeploying the entire app

Yep.  I think this goes with the hot deploy directory above and the  
ability to support unpacked "in-place" deployments.  The key part of  
that description is in-place.  Currently we support unpacked  
deployments but copy all the files to another location.

>  - Remote deployment and management (that is, developer on a different
> machine than server and not FTPing stuff back and forth)

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

I think this is "table stakes" for CMP.  I'm not sure if people are  
willing to hold up 1.0 to do all of this, since almost no one uses  
CMP, but before we claim we have usable CMP we need all of these.

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

I'm working on this, so I planing on having it in anyway :)

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

Most people use it and it should be a trivial conversion of our maven  
plugin.

>  - User documentation
>
>  - Working Pet Store (procedures + deployment plans?)
>
> - 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


P2
-----

* Alternate spring based assembly

I'd like to have an additional spring based assembly available  
quickly, but I don't see reason why it should holdup a 1.0 release of  
the normal server assembly.  The spring based assembly removes the  
desperate need to create tools to deal with the compiled  
configurations, since the configurations are available for direct  
access via a text editor.

> - Move to xmlbeans v2.

There may be a technical reason we have to move to xmlbean v2 before  
Geronimo 1.0, but if not I'd put in the nice to have category.

> - Make sure tx recovery works and build a UI for reviewing problems

I would expect some minimal work in this area for 1.0, but I think we  
should nail this one down in the 1.1 timeframe.

>  - Implement CMP/CMR load groups, to control what fields/relationships
> are loaded when a finder is executed

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

P3
-----
> - A nice usable, and polished management console.

> - Good pluto or other portlet integration.  Also a portlet based  
> management console.

> - Eclipse-based IDE (for J2EE code generation), with a geronimo  
> test environment embedded in eclipse.

> - IDEA plugin

> - NetBeans plugin

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

I completely agree with the sentiment, but I think you are setting  
the goal way to high.  Since people haven't been pounding on or  
working with these apis much, I don't think it is possible not not  
change the interfaces.  Heck the discussion on shutdown hook ordering  
in the Kernel will most likely require an API change, and this is one  
of the most used an inspected interfaces in Geronimo.

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

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

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

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

A good installer would be cool to have.

>  - Provide JSR-88 config beans for all deployment descriptors

Not sure we need this until there are some tools that support dd  
beans. For all I know there could be some now, but I remember last  
time we talked about dd beans there were no tools (other then netbeans).

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

Not sure what you had in mind here.  I doubt you mean that XML  
hacking is not possible, or that is would be a high tech xml editor.   
Do you have more detailed description, or better yet, can you point  
to some tool that does what you are thinking of?

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

I think this goes with the above section.  I don't mind editing xml.   
Heck it works for Apache httpd and Apache Tomcat so I don't see why  
we wouldn't support it.  On the other hand, I don't think it should  
be the only way.  I'm just no clear on the other alternatives our  
users want to see.

> - Start defining APIs and Interfaces that will be supported at 1.0  
> timeframe and going forward.

I don't think this is something we can put on the road map; it is  
just something we do.

-dain

Mime
View raw message