geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: Maven2 Conversation Status
Date Thu, 20 Jul 2006 22:41:23 GMT
Jason,

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.

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

Jason Dillon wrote:
> On Jul 20, 2006, at 2:59 PM, Jeff Genender wrote:
>> IMHO, until its all completely functional and working, I would not wage
>> a +1 for moving it in and deprecating 1.0.  If you are interested in
>> moving in POMs and plugins, then I would be amenable to that.  However,
>> I would not at all be amenable to any sort of deprecation until the M2
>> build is 100% functional.
> 
> What does 100% cover exactly?
> 
>  * * *
> 
> Before when we had talked about removing the m1 build from /trunk the
> objections were that the m2 build was not functional enough for folks to
> work with it on unrelated features/fixes.
> 
> I do not believe that this is the case anymore.  I believe that the m2
> build is quite functional enough for normal development.
> 
> What I am concerned about is the longer we keep m1 and m2 around, the
> larger the gap is going to get between the two systems.  They already
> produce slightly different outputs and there is no way to get them to be
> 100% identical due to the dependency requirements for m1 vs. m2 artifacts.
> 
> Do we run the TCK against the m1 build?  or the m2 build?  or both? 
> That would be a large waste of time and resource IMO.
> 
> The end goal is to use m2, and I believe that right now that m2 is
> functional enough to replace m1 in /trunk.  It is not 100% perfect
> yet... but it is very close.  I believe that it would be the best
> direction for the project to really get the m2 work finished by merging
> in the m2migration changes and then remove the m1 build (and the related
> build artifacts that are left over to support the m1 build that
> duplicate files for the m2 build).
> 
> IMO, the amount of time that it will take to get the m2 build up to 100%
> will be much, much less if there was *just* the m2 build.  Keeping both
> around will probably take 2-5x longer to actually complete to transition.
> 
>  * * *
> 
> But at the same time I would love to deliver the m2 build at 100% now...
> but I think we need more eyes to get there, which means more developers
> and PMC members running the build and testing the distribution.
> 
> I'm positive that you (or someone else) will find something wrong... and
> we will fix it... but I don't think (unless you find something massively
> broken) that it should block the merge to trunk and deprecation and
> removal of the m1 build.
> 
> To be clear(er) I am suggesting a staged move...
> 
>  1) Merge svkmerge/m2migration to trunk
>  2) Deprecate the m1 build (ie... don't use it, use m2, but we leave the
> files as it)
>  3) Remove the m1 build (as another merge from svkmerge/m2migration to
> trunk)
> 
> I believe that, with *active* PMC involvement for the required RTC, that
> we can complete this process in the next few weeks.
> 
> --jason

Mime
View raw message