geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Maven2 Conversation Status
Date Thu, 20 Jul 2006 23:06:42 GMT

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

View raw message