Hey Jeff,
Thanks for the comments. Followups below...
--kevan
On Jul 13, 2007, at 9:24 AM, Jeff Genender wrote:
Kevan Miller wrote:
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?
But what kind of a delay are we really looking at? If Axis certifies
with Tomcat, and Jetty certifies with CXF, by the rules of
transitivity,
there is a pretty good chance Tomcat/CXF and Jetty/Axis will certify
just as easily. If we are not up for releasing 4 (which IMHO is not a
big deal), then we really need to monitor the lists for what
configurations users want. Religious wars abound on web service
containers just as fiercely as the servlet containers do. Why not
consider a quad release for 2.0 and see if it was painful/painless to
run 4 certification runs? Based on the pain threshold, let the
download
count decide at the end of the day for what are default builds?
We don't know what (if any) delay that we're looking at. To date, our
discussions have been that we'll certify both Tomcat/Axis *AND* Jetty/
CXF. That's a perfectly valid plan. As you point out, there's a
decent chance that the alternate permutations are compliant as well,
and we have a certification testing overhead. However, what if some
permutations are not compliant? What if one or more technologies are
not compliant in any permutation? Do we delay release? Or release
with a subset of compliant configurations?
So, our meets-max criteria is certify all permutations of web
container and web services technologies. What's meets-min? If we're
delaying making a decision on our meets-min criteria, then lets say
we'll make this decision at some future date.
With regards to what assemblies do we make available? I like your
idea of making it easy to switch web services technologies. Continue
to deliver Tomcat and Jetty assemblies. The Tomcat assembly defaults
to Axis2 for the Web Services implementation. The Jetty assembly
defaults to CXF. However, by editing the config.xml, either assembly
can be configured to use the alternate Web Services implementation.
As a side note (because I know it will be brought up), I do not
think we
are going down a slippery slope regarding certifying *any*
configuration, and I think we are hitting just the major religious
tones.
Agreed.
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
+1
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.
+1
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.
+1
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).
Those that are SNAPSHOT will need a good prodding and we should
probably
begin that process now.
That process has already begun.
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.
What kind of testing are we talking about. Certainly not a CTS ;-)
Again, by transitivity, if the big ones run, the little ones should
too.
This should be a relatively small obstacle IMHO.
Server starts, you can deploy web apps, the apps work, and the server
can be stopped... Something along those lines. Agreed that this is
small, but do you agree it's a must-have?
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.
+0...since they are on different schedules, I wouldn't hold up one for
the other.
They are different schedules, but IMO there should be some level of
assurance that the plugin can be made to work. If some part of the
server implementation prevents the Eclipse plugin from working with a
2.0 server, is that a stop-release issue?
Nice-to-Haves
+1 on the rest of these.
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
