It's completely different at an API level, and not compatible. It's not just a tool anymore, it's more like a library and it resembles almost nothing to the 2.x codebase.
On 2009-12-29, at 4:18 AM, Arnaud HERITIER wrote: > +1 with Ralph. It is what I have in mind. the problem is that we already > moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will be > lost). > But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X. And > more annoying we are talking about having backward incompatibilities > (removing some stuffs) in 3.1. > I'm not comfortable with that. > > Cheers > > Arnaud > > On Tue, Dec 29, 2009 at 10:14 AM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> 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: >> >>> >>> 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-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> ---------------------------------------------------------- >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
