Jason Dillon wrote: >> 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. >
Ok...well...based on your statement before, you did not clarify this. If I can get an assembly, then this is good. > >> 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. > Ok...so you have a script I can run...have a clean repo...and at the end have a full assembly? If so, then this is somewhat acceptable to me. > >> 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). > Sounds good...get his input. But a TCK build, one way or the other, without manual intervention would be a gate for this IMHO. > >> 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 >
