I would give you a +0 at this point.
You asked what does 100% cover? Based on your description, you
said you
had Jetty working but not Tomcat, unless I read that wrong. IMHO,
that
is not acceptable to begin deprecating M1.
Jetty and Tomcat J2EE and Minimal all work as of yesterday.
100% to me means that I can, from the top of the G tree...with an
empty
m2 local repo, do a "mvn install" and minimally end up with a tomcat
J2EE, jetty J2EE, and little-G assemblies on the back end.
As of right now "mvn install" from an empty repo will never work due
to issues with Maven that are pending fixes in 2.0.5.
This is what the 'build' script resolves.
Also due to the OpenEJB2 jars built with m2 not being published, due
to G 1.2 jars built with m2 not being published, you need to manually
compile OpenEJB2 w/m2 half-way through the m2 build of G 1.2.
This is what the 'bootstrap' script resolves.
So, if you replaced "mvn install" with "bootstrap" then the above
statement is accurate.
As for the TCK, I would suggest you garner other comments, in
particular, those from folks who work with the TCK daily. If we are
unable to run the TCK because all of our artifacts are in a M2 repo,
then this kind of makes our ability to release nearly impossible.
I agree, need to get some input from Keven to see what is needed to
get the TCK running off of the m2 build. I think that can happen in
parallel to the first step (or steps if you include deprecation of m1).
I would like to alter your suggestions slightly. I would recommend:
1) Merge m2 into trunk when M2 can build assemblies from a clean
local repo.
2) Work on a TCK m2 and get it working.
3) Merge in the TCK m2 to trunk.
4) Deprecate M1.
I cannot support removing/deprecating the M1 build until we can build
assemblies and have a working TCK.
Jeff, I believe (strongly) that it is very important to deprecate
(not remove, but deprecate) the m1 build ASAP to prevent widening the
gap of differences between the outputs of the two builds.
--jason
