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. >> 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 ;-) >> >>> >>> 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
