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
