maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@sonatype.com>
Subject Re: Maven 2.2.2 soon?
Date Tue, 29 Dec 2009 15:40:33 GMT

On 2009-12-29, at 4:14 AM, Ralph Goers wrote:

> As I understand it, 3.0 now consists of significant refactoring of the internals but
no major changes externally.

This was decided after how much work we've done I figured trying to bring the community forward
on a version of Maven that was a real replacement was more important. By a real replacement
I mean one that can be patched, is easier to navigate at the source level, have better tests,
and remove some of the architectural problems that would prevent building interesting features
that we want in the future. This took a lot of work and I think pushing out POM changes and
potential interoperability problems just isn't worth it. The message is Maven 3.x is a drop
in replacement and we'll build upon that for the future.

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

No, I think 3.0 is appropriate. Just the embedder changes alone there are radical API changes.
From the CLI perspective users aren't going to notice much. At least they shouldn't. But all
the new m2eclipse relies on all these changed APIs and the Polyglot Maven in the works is
also dependent on all those changes. It's significant enough at the API level to call it 3.0.

> Ralph
> 
> On Dec 28, 2009, at 9:12 PM, Jason van Zyl wrote:
> 
>> 
>> On 2009-12-28, at 10:34 PM, Brett Porter wrote:
>> 
>>> 
>>> On 29/12/2009, at 1:39 PM, Brian Fox wrote:
>>> 
>>>> Is there anything pressing that calls for a 2.2.2? The 3.0's are
>>>> moving along and are quite usable.
>>> 
>>> I was just thinking of shipping the existing fixes and anything obvious or regressed
in 2.2.1.
>>> 
>>> On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> 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. 
>> 
>> 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.
>> 
>>> 
>>> 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.
>> 
>> 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.
>> 
>>> 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.
>> 
>> 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.
>> 
>>> 
>>> For example, where are the issues that reflect switching to Guice and OSGi that
we keep hearing about?
>> 
>> 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.
>> 
>> 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.
>> 
>> There is plenty to do with 3.0 without Guice and OSGi.
>> 
>>> 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?
>> 
>> 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.
>> 
>> 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.
>> 
>>> 
>>> 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.
>>> 
>> 
>> 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.
>> 
>>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>> 
>> 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.
>> 
>>> - Brett
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


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


Mime
View raw message