Jeff Genender wrote:
Kevan Miller wrote:
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?
I think we should give it a shot and if it looks like its going to pass
or a small fix, then lets do it. If it shows major errors, then sweep
it under the rug for the time being and drop the 4 idea. Lets certainly
not delay, but lets run 'em. Best case scenario is they pass and we
have 4 releases. Worst is they don't pass and we fall back to the
original plan.
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.
Meets-min == original plan.
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.
Yep, but I think its a better sell at the end of the day to have all 4
to met the religious needs. Again, we can always fall back to what you
stated above.
Just to be clear ... the "4" assembly solution actually involves 6
(maybe 7 assemblies) of which we would only certify 4.
- tomcat javaee5 with axis2
- tomcat javaee5 with cxf
- jetty javaee5 with axis2
- jetty javaee5 with cxf
- tomcat minimal
- jetty minimal
- micro-G (Geronimo framework) is still included in the build as an
assembly as well. We could choose to skip this assembly for the release
as our plugin story still isn't complete ... but we delivered this in 1.2
That looks like a lot of assemblies to me. I'd personally prefer to
ship just 4 (or 5) assemblies total with just 2 javaee5 assemblies. We
could still certify all 4 javaee5 permutations even if we don't ship
unique assemblies. However, I think this is a "nice to have" rather
than critical ... time and severity of problems would push us to claim
certification for just 2 (maybe even just 1) configuration.
Anybody have any idea/guess how many users are mostly concerned with the
minimal assemblies? If most users (or a significant number) are on
minimal then we might be spending too much energy trying to decide how
many javaee5 permutations to deliver for very little user benefit. Even
if we deliver just the 2 javaee5 assemblies the users that have a strong
opinion can easily reconfigure the server. My hunch is that most of the
strong opinions are developer opinions rather than opinions based upon
user needs.
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?
Yep...was just commenting on the criticality level ;-)
Agreed here as well. It sounds like a lot of our users are using
minimal so we want to make sure we don't break them.
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?
IMNSHO..no. I still see them as 2 separate products...and not everyone
uses Eclipse (well I do), so I would be against holding up G for the
Eclipse plugin.
Jeff
