On Jun 21, 2007, at 12:34 PM, Matt Hogstrom wrote:
We've gone through the CTS grind and came out victorious http://
java.sun.com/javaee/overview/compatibility.jsp
OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is
working that way too.
All in all its been an excellent six months.
So, what are we going to do for 2.0 and getting it out the door?
Here are my thoughts and we can use this thread to gather everyone
else's and come to a consensus.
2.0 Ship Criteria
Date: mid to end of July (a target only...depends on content)
Certified Assemblies
Tomcat, Axis 2 and OpenJPA
Jetty, CXF and OpenJPA
Other assemblies would be the minimal assemblies but cert doesn't
apply to them.
Work on fit and finish stuff (cleaning up error messages, improving
diagnostics, reducing footprint).
Personally, I'd like to see the full G have a footprint of about
40MB (that's a little over 5MB larger than 1.1.1) and Minimal be
around 20MB. Need to do some research on this (volunteers?)
I'm not sure how the WADI clustering presents itself across the two
different assemblies (Gianny, comments?)
Beneficial, I think, to conclude/summarize this discussion as we move
forward to finalizing release plans and dates. Since I'm introducing
some potentially "new" categorizations, I'm not calling this a
summary, yet...
In release discussions, like this, I'd like to see us be a little
clearer with regard to our "must-haves" and "nice-to-haves". In that
regard, the following is my evaluation of the criteria that we've
been discussing:
Must-Haves
1. Certification. For M6 we certified a Tomcat/CXF configuration of
Geronimo. We'd like to certify 2.0 using Jetty and Axis2, also. What
configuration combinations *must* be certified? Is a single certified
configuration sufficient? Or do we want to certify with multiple
configurations? In an ideal world, I think we'd certify all 4
combinations of Web Container and Web Services implementations.
What's our must have set? From discussions to date, it seems to be
Tomcat/Axis2 and Jetty/CXF. However, are we willing to delay a 2.0
release until both configurations are certified?
2. Fit and Finish. The "must-have" list would include Release Notes,
appropriately licensed source files, and up-to-date license and
notice files. Other "Fit-and-Finish" items have been proposed. All
are good ideas. However, in my book, they fall into the "nice-to-
have" category and are included below. I'd like to be careful with
this category. Otherwise, we end up with an always shifting target
3. Additional Features. With Gianni's latest WADI updates, I believe
that people are happy with the current set of functionality. Now
would be a really good time to voice any disagreements. ;-) This also
implies that we should be careful about starting new function
development on trunk. Also begs the question of when we move "2.0"
off of trunk and into a branch... I know some people are holding off
new function until 2.0 has been branched.
4. Bug Fixes. Recent testing with DayTrader has identified several
deployment and memory-related problems which seem to fall into the
must-fix category. David J had a problem with manifest classpaths
that he was fixing. If we have other must-fix bugs, we should call
them out now. Naturally new must-fix problems may be raised prior to
release. However, we should avoid last minute surprises.
5. Dependencies. A number of our dependencies are SNAPSHOT
dependencies. Many of these projects have or are in the process of
being released. Very difficult/impossible to get *all* projects lined
up on a release train. Also, likely that we'll have to Geronimo
specific builds of some projects (e.g. Tomcat).
6. Little-G. I don't know of much testing that's occurred of our
Little-G configurations. We need to perform a basic validation of
these assemblies.
7. Eclipse Plugin. This won't release concurrently with 2.0. However,
we should insure that it's on target for release shortly after the
server release.
Nice-to-Haves
1. Fit and Finish. Reducing download and runtime size have been
proposed as potential improvements. There was a fair amount of
discussion regarding download size. However, I don't see much active
work occurring. Improving performance is always nice... ;-) There was
also discussion of removing duplicate artifacts from our assemblies
(i.e. being smarter about what artifacts are being included by the
maven2 war plugin and cleaning up some of our configurations) -- it
would be great to see some of these issues fixed. However, IMO, it
need not hold up a release.
2. Usability. There are a number of usability improvements (e.g.
improved messages and diagnostics) which have been proposed. There
has been progress in this area already. My sense is we're ready to go
with what we've got. We can make incremental improvements, of course.
However, I don't see a complete overhaul prior to 2.0 in the works...
3. Additional Features. As mentioned previously, we want to be
careful about introducing new instabilities (I mean features ;-).
4. Bug Fixes. We can be a bit more aggressive, here. However, I think
we need to still weigh potential instabilities against the
anticipated benefits.
--kevan
