On Jun 14, 2005, at 8:28 AM, Stephane Bailliez wrote:
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?
It would be nice to have at least an idea of what you think about
the roadmap ? What do you expect from the 1.0 ? A certified J2EE
container with plumbing or a certified j2ee container with fancy
consoles and features ? What do you expect from the M4 ?
M4 : I'd like to do that ASAP :)
1.0? I think that it should be certified of course to ensure that
the J2EE functionality is there, but also some bit of "fit and
finish" for basic tooling and usability.
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.
Ye - but we want to make that bare minimum usable :)
I'm setting the following priorities, for the sake of starting with
something, but this needs more iteration on the definition of it:
P1: Cannot have a 1.0 release without this feature
P2: Nice to have. Can wait 1.0+ release
P3: Very nice to have, can wait a 1.1+ release.
Ok - I'll recapture this and Aaron's feedback in another checkpoint
summary. Anyone else feel free to comment w/ P1, P2, P3 and we can
collect...
My comments inline
Usability/Tooling
=================
- A nice usable, and polished management console.
P3
P2: would be for a minimal UI.
A lot of low-end j2ee apps are deployed without ever using the
admin ui, this is mostly a fire and forget deployment, so this is
why I'm putting that as a non-P1
- 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).
P2
- True hot deploy/undeploy (is this working? or does it need
work? I have been somewhat unsuccessful without some form of
restart)
P1
- Sniffable deploy directory. It would be nice to drop EAR/WAR/
etc in a directory and have it auto deploy, at least for development
P1
- Eclipse-based IDE (for J2EE code generation), with a geronimo
test environment embedded in eclipse.
P3
- IDEA plugin
P3
- NetBeans plugin
P3
- Start defining APIs and Interfaces that will be supported at
1.0 timeframe and going forward.
P1
- 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.
P1
- Good pluto or other portlet integration. Also a portlet based
management console.
P3, but this has to be thought from the ground up as it could
impact the UI console from an architecture POV. Who knows, the UI
console could well be a pluto-based portal.
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.
Could you please clarify from a feature point of view what it brings ?
I'll let the contributor of that one comment...
- 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.
P2 (but it does no go as it does not involves breaking
configuration for every release)
- 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.
P1
- Move to xmlbeans v2.
P2. What is the move justification ? What does it brings ?
I think we have to do a few unnatural acts to work w/ xmlbeansV1.
IIRC V1 defines a few classes like QName that cause some havoc...?
- Make sure tx recovery works and build a UI for reviewing problems
P2. tx is of critical use in apps but I doubt anyone will use
Geronimo for critical apps for a while. So this gives a bit of time
to consolidate.
- True clustering with rolling deployments (i.e. deploy but don't
activate until I say I am ready).
P2. Same as above.
- Performance - get performance suites to run
P2+ .
- Performance - once running, start looking at optimization and
enhancement for performance
P2+
Other
=====
- QA test plan
P1+
- QA test resources (people, computers)
P1+. Can you clarify exactly what is your plan on this ? Does that
mean that IBM plans to invest for some QA resources for Geronimo ?
Not only IBM. Anyone that wants to help -
For example, we could use systems w/ different OSs, JVMs, DBs that
are used for continuous integration testing.
- M4 milestone release
P1E999
- nightly build generation and maintenance
P1E9999999
- harvest good material from the wiki and add to website
Uh ? Is that necessary ? What kind of information do you want to
harvest ? IMHO you should not duplicate the source of information.
Well, lots of the wiki is out of date. Cruft tends to accumulate.
There are things like "how to build" which are things that every new
developer wants to know, and we can have that available on the
website (or linked to the wiki from the website) as the website is
the first place people come to.
The current problem with the website is that it is stalled
information. It does not show real activity (it has been mentioned
numerous times already) while there is a tremendous effort going
on...but no one knows on what. This is the problem IMHI. We should
avoid adding quantitative information, but qualitative and avoid if
possible multiple sources.
Sorta. The website has just been re-done, and there should be no
more stall. If you have a suggestion for the site, throw it out and
we'll do it ASAP if reasonable, or - as always - send a patch.
- find donated access to platforms for CTS certification to build
a big compatibility matrix
External people cannot have any info on that. correct ?
Right - this would be for the use of the peeps doing cert, but the
matrix of where we certified is certainly public knowledge.
I may add:
* 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
yes!
P1
* Add migration HOW-TOs from known app. servers (try to see if we
could use a migration tool ?)
P2
yes. And yes, having tools would be great.
My 0.02 cents :)
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
