Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.211.203 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: Maven 2.2.2 soon?
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: <880523E4-3458-44A9-BFAF-BA25771EF165@sonatype.com>
Date: Tue, 29 Dec 2009 01:14:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <263580E4-A6DF-4BBD-8B43-D132A9CA6D56@dslextreme.com>
References: <b9e663070912260234u2cc3dfcena5e01e6aed902791@mail.gmail.com>
 <FB9911EE-C5A6-4019-91DB-A0D66B5CFD5A@apache.org>
 <eb0f802d0912281839t1c25b171s7df3973f115abb71@mail.gmail.com>
 <0D8D2C09-649F-4DE0-AF58-538FB2B9F146@apache.org>
 <880523E4-3458-44A9-BFAF-BA25771EF165@sonatype.com>
To: "Maven Developers List" <dev@maven.apache.org>

As I understand it, 3.0 now consists of significant refactoring of the =
internals but no major changes externally. I originally expected 3.0 =
would have some impact on the pom schema but I don't think even that has =
occurred. Given all this is 3.0 really the appropriate version number?  =
I usually associate a change to the major release number with something =
that will significantly impact the customer.  I understand that all of =
this stuff is foundationally necessary to make some of these changes but =
it would seem more appropriate for this to be 2.5 and go to 3.0 when =
something significant is added that an end user will notice.

Ralph

On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:

>=20
> On 2009-12-28, at 10:34 PM, Brett Porter wrote:
>=20
>>=20
>> On 29/12/2009, at 1:39 PM, Brian Fox wrote:
>>=20
>>> Is there anything pressing that calls for a 2.2.2? The 3.0's are
>>> moving along and are quite usable.
>>=20
>> I was just thinking of shipping the existing fixes and anything =
obvious or regressed in 2.2.1.
>>=20
>> On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
>>=20
>>> I think that the 3.x code is far enough along that if anyone is =
going to do any work I think that enough work has been done in 3.x to =
stop working on 2.x.
>>>=20
>>> So much has been fixed, tested and tuned that at this point after =
using 3.x for a long time and with the tests that are in place that I'd =
really like to flatten all the 2.x versions in JIRA and toss them into =
the 3.x bucket. Then scour the issues and just throw out anything that =
remotely looks like garbage, close things out and get people to test =
against 3.x and try and get the issue count down to the nuggets that are =
really going to be new features or are really bugs.
>>=20
>> Might as well, that's realistically the situation anyway. Nobody is =
going to do major work on 2.x faced with uncertain prospects in porting =
it over to 3.x. Keep anything purely specific to 2.x in the 2.2.x bucket =
and move bigger stuff out.=20
>=20
> There's not really much to port really at this point. The ITs can =
always be improved but there is a pretty rock solid set of tests there.
>=20
>>=20
>> But we have to be 100% focused on shipping 3.0 if that's the case. =
You can't put an end to 2.2.x when there's no end in sight to 3.0.
>=20
> I am not interested in 2.x, but that's why I asked if anyone else was =
interested in working on it. I'm not putting an end to 2.x, I'm just not =
going to work on it anymore.
>=20
>> JIRA needs to reflect exactly what needs to be done for 3.0-alphas, =
betas and final so we can start counting down. It's fair enough to not =
specify a date, but at least the target needs to be in sight to get =
anyone inclined to help with polishing work.
>=20
> It's primarily testing work that needs to be done. The site plugin is =
probably the only hole that needs to be filled as that one will affect a =
lot of users.
>=20
>>=20
>> For example, where are the issues that reflect switching to Guice and =
OSGi that we keep hearing about?
>=20
> Neither of those are going to happen in the 3.0 time line. We've got =
Nexus running on Guice (with a Plexus shim) now and we need to run that =
through the grinder for a while. When that works we can take a look at =
Maven. Nexus uses almost everything in Plexus that Maven does and we've =
not had to change any of code. The Plexus shim adapts everything =
necessary. But we'll have to add to the shim to account for some Maven =
particulars because all the old code has to work. This is not a small =
job, but we've got to get Maven off Plexus pronto. We are not attempting =
to do the Guice + OSGi in one shot in Nexus and we shouldn't attempt =
this with Maven in one shot either. Stuart could probably get Maven =
working with Guice for 3.0 but I think that would be pushing it. So I =
think it best to take Guice out of the 3.0 deliverable.
>=20
> The OSGi runtime will likely follow what we're doing in Nexus. After =
getting Guice working as a replacement for Plexus we will attempt to get =
Nexus running on Guice + Peaberry for OSGi and then we'll run that =
through the grinder as well. We don't know how long that will take, the =
Guice stuff is working now but the OSGi is a whole other story. A =
repository of bundles doesn't really exist (we're trying to fix that =
with osgi.sonatype.org) and all the dependencies would need to be =
bundle-ized. So we're trying to add a feature to Nexus to turn any JAR =
into a bundle on the fly. This is fraught with problems. So I can say =
pretty definitively no Guice or OSGi for 3.0, but can easily happen in a =
3.1. Ultimately to users they shouldn't notice anything, and that's just =
a lot of testing.
>=20
> There is plenty to do with 3.0 without Guice and OSGi.
>=20
>> I just added one for slf4j that you mentioned. What other things are =
planned that are not in there so we can drive towards a goal?
>=20
> I think we're done to be honest. If JIRA could be trimmed down, by =
clearing out the silliness, and starting to validate that issues marks =
as bugs have been fixed in 3.x then that will get us most of the way =
there. For what remains trying to bug fix and write ITs is really the =
only thing left I really want to tackle. If crap pops up that we need to =
fix for m2eclipse I would probably sneak in but otherwise testing and =
validation is largely what remains.
>=20
> Using SLF4J as the API will really amount to working over time at =
injecting a logger with the SLF4J API instead of the Plexus API one. At =
very least maybe we can cleanup the Plexus SLF4J stuff so that if we do =
provide a way to configure the logging using standard SLF4J stuff it =
won't change when we change the API internally. We are doing a lot of =
logging and tracing work in Nexus and M2Eclipse right now so some of =
this might fall out of that and go back into Maven but if someone else =
wants to tackle that it would be cool.
>=20
>>=20
>> I'd also avoid planning 3.1 alphas at this stage. Focus on getting =
3.0 out, and everything else that is after 3.0 can be up for grabs.
>>=20
>=20
> There I'm only trying to collect things that we cannot change in 3.0. =
If I've seen things like POM changes I've just been pushing it into =
3.0.alpha1.
>=20
>>>=20
>>> There are ~650 issues and I think in four weeks with a little =
teamwork we can probably drive that down to the 50 things we care about.
>>=20
>> I'm happy to help clean up issues, sure. I make a small dent in it =
occasionally, but it tends to sap any energy before starting to do any =
actual work.
>>=20
>=20
> I'll make another pass. I'm sure there are a ton of duplicates, and =
stuff that's actually been fixed in 3.x. It really is just a lot of =
validation work and writing ITs. Any works that needs to be done will =
really only be for fixing compatibility issues at this point.
>=20
>> - Brett
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>=20
>=20
> Thanks,
>=20
> Jason
>=20
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org