You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Benedict <pb...@apache.org> on 2009/12/26 11:34:16 UTC
Maven 2.2.2 soon?
I know the drive for 3.0-alphas are on, and 2.0.10 is baking for a
release. Will 2.2.2 be revisited soon? If nothing is pressing, well,
that's alright too.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
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.
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.
On 2009-12-26, at 5:34 AM, Paul Benedict wrote:
> I know the drive for 3.0-alphas are on, and 2.0.10 is baking for a
> release. Will 2.2.2 be revisited soon? If nothing is pressing, well,
> that's alright too.
>
> Paul
>
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
On 30/12/2009, at 2:19 AM, Brett Porter wrote:
> Yep... would it be ok to just fold all those into a "3.1" version and split that into buckets later when it is being worked on, to reduce the noise?
I just did that since there was only one issue in 3.1 (a dupe) and none in 3.1.alpha.2.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
On 29/12/2009, at 4:12 PM, Jason van Zyl wrote:
>>
>> 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.
Ok, I think there has been some confusion on this and other parts in terms of timing. It makes it much easier to understand where things are going if the JIRA roadmap (post-cleanup) reflects reality.
>> 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.
+1
>
> 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've mucked with this a number of times to unify things so don't mind working on it, but it seems more like a 3.1 thing to tackle because of the repercussions it might have. Also, doesn't OSGi provide logging facilities that it might be better to take advantage of if it is going to be there?
>
>>
>> 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.
Yep... would it be ok to just fold all those into a "3.1" version and split that into buckets later when it is being worked on, to reduce the noise?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: M3, plexus and guice ?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/12/30 Kristian Rosenvold <kr...@gmail.com>
> Jason van Zyl wrote:
>
> > I honestly think it will be easier for people to get involved in the 3.0
> codebase.
>
> Somewhere along the line in the flurry of emails that have been coming
> along today I got the impression that a transition to guice has been
> called off for M3.
>
Hi Kristian,
I doubt it will make 3.0, but this isn't necessarily a bad thing as it means
we're
not changing a lot of things at once. We used Nexus as an early adopter to
test
and stabilize the shim code, which really helped nail down some issues - and
it
should soon be time to try it with Maven.
Right now I can run exactly the same Nexus binaries with Plexus or
Guice+shim
- no code changes required. Supporting Maven means extending the shim which
shouldn't be a huge piece of work, especially if other people help out :)
When complete we should be able to drop it into 3.1 without breaking anyone.
I think that's a shame, and having only recently gotten a little "more
> involved" with the maven code-base, I have felt the pain that plexus can
> inflict.
>
> I will try not to start any plexus-bashing, but given the discussion
> that has been going on today about how M3 is a significant cleanup of
> inner workings, I find stopping before getting rid of plexus strange.
>
Many legacy plugins will continue to use Plexus annotations to inject
components,
so we need to be compatible - hence the shim (provides Plexus API and
semantics
on top of vanilla Guice).
When we first switch to the Guice-powered runtime these components and
plugins
will continue to use Plexus annotations like @requirement, but it'll be
Guice doing
the actual wiring. What happens next is the really interesting bit...
I would be more than willing to spend a fair amount of time to make such
> a transition happen, the sooner the better. Especially if there already
> is a working plexus/guice adapter that can be used as basis. I get this
> feeling I missed some discussion somewhere ?
>
The code is available at http://svn.sonatype.org/spice/trunk/spice-inject -
I'm just
finishing up the last Nexus related issue and sorting out documentation, as
well
as writing one or two blog entries about the new runtime. The code is
modular,
so you could use it to to mimic other IoC containers on top of Guice.
I'll put together some notes explaining how I did the shim analysis for
Nexus, as
we'll need to do the same for Maven (it uses a slightly different version of
Plexus)
Thanks for the offer of help!
But then again, we all must release sometime - I just needed to vent
> my frustration with plexus. Switching to guice also has a motivational
> effect on people wishing to work with the maven codebase; developers
> like to work with code they feel is "hot".
>
Once the shim is done the really interesting work can start: making the most
of the
new runtime. Such as switching plugins over to use @Inject, contributing
your own
Guice bindings, etc. Nothing's written in stone yet, so there's plenty of
opportunity
to experiment and find best practices for getting the most from the runtime.
Small steps, but important steps :)
> Regards
>
> Kristian Rosenvold
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Cheers, Stuart
Re: M3, plexus and guice ?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/12/30 Brett Porter <br...@apache.org>
>
> On 30/12/2009, at 9:07 AM, Christian Edward Gruber wrote:
>
> > Hey Jason. Please keep me in the loop on this. I'll hapily contribute,
> since I'm hoping to improve docs on guice this upcoming quarter or two, and
> I don't want to lose my maven-fu whilst in the midst of Google's build
> toolset.
>
> Even if the code isn't directly in SVN, I think it makes sense to have that
> discussion here - something that important needs everyone to understand what
> is going on and various people will notice corner cases and gotchas. That
> seemed to work well for the parallel builds with the occasional updates
> (something that needs to be evaluated for preparedness for whichever version
> too...)
>
definitely - I'll finish up the docs and send out a link so people can
review them along with the code.
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Cheers, Stuart
Re: M3, plexus and guice ?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/12/30 Brett Porter <br...@apache.org>
>
> On 30/12/2009, at 9:07 AM, Christian Edward Gruber wrote:
>
> > Hey Jason. Please keep me in the loop on this. I'll hapily contribute,
> since I'm hoping to improve docs on guice this upcoming quarter or two, and
> I don't want to lose my maven-fu whilst in the midst of Google's build
> toolset.
>
> Even if the code isn't directly in SVN, I think it makes sense to have that
> discussion here - something that important needs everyone to understand what
> is going on and various people will notice corner cases and gotchas. That
> seemed to work well for the parallel builds with the occasional updates
> (something that needs to be evaluated for preparedness for whichever version
> too...)
>
Hi folks,
FYI, we've started a series of articles describing our initial work
extending Guice to support Plexus:
http://www.sonatype.com/people/2010/01/from-plexus-to-guice-1-why-guice/
http://www.sonatype.com/people/2010/01/from-plexus-to-guice-2-the-guiceplexus-bridge-and-custom-bean-injection/
http://www.sonatype.com/people/2010/01/from-plexus-to-guice-3-creating-a-guice-bean-extension-layer/
The above articles just introduce general bean injection, they don't cover
Plexus specific behavior.
I'll give an overview of what we have relating to Maven / Plexus in the blog
either this week or next
and we can then discuss and hash out the fine details relating to Maven3 on
the wiki.
--
Cheers, Stuart
- Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
Re: M3, plexus and guice ?
Posted by Brett Porter <br...@apache.org>.
On 30/12/2009, at 9:07 AM, Christian Edward Gruber wrote:
> Hey Jason. Please keep me in the loop on this. I'll hapily contribute, since I'm hoping to improve docs on guice this upcoming quarter or two, and I don't want to lose my maven-fu whilst in the midst of Google's build toolset.
Even if the code isn't directly in SVN, I think it makes sense to have that discussion here - something that important needs everyone to understand what is going on and various people will notice corner cases and gotchas. That seemed to work well for the parallel builds with the occasional updates (something that needs to be evaluated for preparedness for whichever version too...)
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: M3, plexus and guice ?
Posted by Christian Edward Gruber <ch...@gmail.com>.
Hey Jason. Please keep me in the loop on this. I'll hapily
contribute, since I'm hoping to improve docs on guice this upcoming
quarter or two, and I don't want to lose my maven-fu whilst in the
midst of Google's build toolset.
Regards,
Christian
also cgruber@google.com
Sent from my iPhone.
On 2009-12-29, at 14:40, Jason van Zyl <ja...@sonatype.com> wrote:
> On 2009-12-29, at 2:27 PM, Kristian Rosenvold wrote:
>
>>
>>> If you like we can probably setup a git repo with a shimmed
>>> version of Maven and you can start putting it through it's paces.
>>> I can sync you and Stuart up offline and you can work on it when
>>> you can.
>>>
>>
>> Sounds nice. I'll read up on the code. I need to get started with
>> some
>> seriously long skiing trips to get rid of the christmas excess. I
>> seem
>> to program well when sweating ;)
>>
>
> Ok, we'll try and set something up quickly with at least
> instructions of what dependencies to use. Maybe we can make a
> profile which uses one set of dependencies over another. For the
> trunk build itself using Guice over Plexus will really just be a
> slightly different set of artifacts. We'll try to get that sorted
> out and get you on your way.
>
>> Kristian
>>
>>
>>
>>>> Kristian
>>>>
>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: M3, plexus and guice ?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 2:27 PM, Kristian Rosenvold wrote:
>
>> If you like we can probably setup a git repo with a shimmed version of Maven and you can start putting it through it's paces. I can sync you and Stuart up offline and you can work on it when you can.
>>
>
> Sounds nice. I'll read up on the code. I need to get started with some
> seriously long skiing trips to get rid of the christmas excess. I seem
> to program well when sweating ;)
>
Ok, we'll try and set something up quickly with at least instructions of what dependencies to use. Maybe we can make a profile which uses one set of dependencies over another. For the trunk build itself using Guice over Plexus will really just be a slightly different set of artifacts. We'll try to get that sorted out and get you on your way.
> Kristian
>
>
>
>>> Kristian
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: M3, plexus and guice ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
> If you like we can probably setup a git repo with a shimmed version of Maven and you can start putting it through it's paces. I can sync you and Stuart up offline and you can work on it when you can.
>
Sounds nice. I'll read up on the code. I need to get started with some
seriously long skiing trips to get rid of the christmas excess. I seem
to program well when sweating ;)
Kristian
> > Kristian
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: M3, plexus and guice ?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 1:57 PM, Kristian Rosenvold wrote:
> On Tue, 2009-12-29 at 13:25 -0500, Jason van Zyl wrote:
>
>> Taken us longer to make the adapter then we expected, and if we want 3.0 out in a reasonable timeframe it's just not something we can do.
>
> Oh that's a shame, and you're totally right I probably don't see the
> full ramifications. I suppose I must have missed that bit if it was
> discussed on the list.
>
>> Well, I'm not really concerned as a first priority whether you think the code is "hot".
>
> I wouldn't care about "hotness" as a feature either, but there is a very
> real motivational factor for getting people involved. At least in my day
> job I find that people are a lot more motivated to learn/use tools &
> frameworks they see as good for their personal evolution as developers.
>
> But you're totally right; most of the change should be invisible to the
> outside and it should be an undramatic change if done properly.
>
>
>> The Plexus shim for Guice is here:
>>
>> http://svn.sonatype.org/spice/trunk/spice-inject/
>>
>
> I will definitely take a look at that, thanks.
>
If you like we can probably setup a git repo with a shimmed version of Maven and you can start putting it through it's paces. I can sync you and Stuart up offline and you can work on it when you can.
> Kristian
>
>
>
> ---------------------------------------------------------------------
> 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
Re: M3, plexus and guice ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
On Tue, 2009-12-29 at 13:25 -0500, Jason van Zyl wrote:
> Taken us longer to make the adapter then we expected, and if we want 3.0 out in a reasonable timeframe it's just not something we can do.
Oh that's a shame, and you're totally right I probably don't see the
full ramifications. I suppose I must have missed that bit if it was
discussed on the list.
> Well, I'm not really concerned as a first priority whether you think the code is "hot".
I wouldn't care about "hotness" as a feature either, but there is a very
real motivational factor for getting people involved. At least in my day
job I find that people are a lot more motivated to learn/use tools &
frameworks they see as good for their personal evolution as developers.
But you're totally right; most of the change should be invisible to the
outside and it should be an undramatic change if done properly.
> The Plexus shim for Guice is here:
>
> http://svn.sonatype.org/spice/trunk/spice-inject/
>
I will definitely take a look at that, thanks.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: M3, plexus and guice ?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 12:48 PM, Kristian Rosenvold wrote:
> Jason van Zyl wrote:
>
>> I honestly think it will be easier for people to get involved in the 3.0 codebase.
>
> Somewhere along the line in the flurry of emails that have been coming
> along today I got the impression that a transition to guice has been
> called off for M3.
>
Taken us longer to make the adapter then we expected, and if we want 3.0 out in a reasonable timeframe it's just not something we can do.
> I think that's a shame, and having only recently gotten a little "more
> involved" with the maven code-base, I have felt the pain that plexus can
> inflict.
>
In all honestly it affects almost no users. You're an advanced user, and we've had the same problems with Guice and we've had to create some shim code and make some changes in Guice as well. Nothing is perfect but leaving Plexus in 3.0 isn't going to affect average users. If the ITs work I don't see much value in rushing the switch. We testing all the edges with Nexus and when that's done we'll try Maven.
> I will try not to start any plexus-bashing, but given the discussion
> that has been going on today about how M3 is a significant cleanup of
> inner workings, I find stopping before getting rid of plexus strange.
>
Then you don't really understand how much work it is. It's impossible for anyone to see this when they don't work on this full-time.
> I would be more than willing to spend a fair amount of time to make such
> a transition happen, the sooner the better. Especially if there already
> is a working plexus/guice adapter that can be used as basis. I get this
> feeling I missed some discussion somewhere ?
I don't think you honestly understand the ramifications of changing the underlying system. The grid has slowly been built up over time to try and automate much of this and the ITs catch almost everything these days but it's not a small or trivial job. When we have found problems Stuart has been able to work with Jesse to patch Guice but we're still finding things and we fix them as we go. I think it's wiser to fully convert one system completely first, in this case Nexus, and then attempt the next system.
>
> But then again, we all must release sometime - I just needed to vent
> my frustration with plexus. Switching to guice also has a motivational
> effect on people wishing to work with the maven codebase; developers
> like to work with code they feel is "hot".
Well, I'm not really concerned as a first priority whether you think the code is "hot". I care about it being stable, making sure the grid is in place to catch anything, and that the ITs actually represent something we can rely on.
The Plexus shim for Guice is here:
http://svn.sonatype.org/spice/trunk/spice-inject/
Stuart has started playing around trying to get this to work with Maven but, again, we're focusing on Nexus first. But if you want to setup some builds and give feedback, patch guice, help setup the tests on the grid for validation and help write new ITs then that would be great. Myself, Stuart and Benjamin would be happy to get you started and point you in the right direction.
Given what I know about how the resources available to work on this and the general level of activity in the core I don't see Guice getting in for 3.0. But if it can be proven that a version of Maven running on top of Guice is a viable replacement then users won't notice and it can go in when it's ready somewhere along with 3.0.x line.
>
> Regards
>
> Kristian Rosenvold
>
>
>
>
> ---------------------------------------------------------------------
> 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
M3, plexus and guice ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
Jason van Zyl wrote:
> I honestly think it will be easier for people to get involved in the 3.0 codebase.
Somewhere along the line in the flurry of emails that have been coming
along today I got the impression that a transition to guice has been
called off for M3.
I think that's a shame, and having only recently gotten a little "more
involved" with the maven code-base, I have felt the pain that plexus can
inflict.
I will try not to start any plexus-bashing, but given the discussion
that has been going on today about how M3 is a significant cleanup of
inner workings, I find stopping before getting rid of plexus strange.
I would be more than willing to spend a fair amount of time to make such
a transition happen, the sooner the better. Especially if there already
is a working plexus/guice adapter that can be used as basis. I get this
feeling I missed some discussion somewhere ?
But then again, we all must release sometime - I just needed to vent
my frustration with plexus. Switching to guice also has a motivational
effect on people wishing to work with the maven codebase; developers
like to work with code they feel is "hot".
Regards
Kristian Rosenvold
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 11:25 AM, Ralph Goers wrote:
>
> On Dec 29, 2009, at 7:40 AM, Jason van Zyl wrote:
>
>>
>> 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 didn't mean it as a criticism. Just that 3.0 started out with one target in mind and is now something completely different.
>
Not really. Most of what we want to do now is possible. It's not technically hard to make POM changes at this point, but it's more a matter of the interoperability plan and our ability to test. But the internals are very different.
> At some point we HAVE to do something about making the pom extensible. It just doesn't contain enough information to solve some of the problems. This could be done if Maven would tolerate stuff it doesn't understand. It would be best if this could be done sooner rather than later. i.e., that alone would justify a 2.2 release.
>
Yes, but I don't think anyone understands how hard this actually is. The 3.0 internals will allow this now, that's not actually a technical problem anymore.
> Since I haven't done any of the work on 3.0 I'm not going to make a big deal out of what the version number of the release should be.
>
I honestly think it will be easier for people to get involved in the 3.0 codebase.
> Ralph
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2009, at 7:40 AM, Jason van Zyl wrote:
>
> 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 didn't mean it as a criticism. Just that 3.0 started out with one target in mind and is now something completely different.
At some point we HAVE to do something about making the pom extensible. It just doesn't contain enough information to solve some of the problems. This could be done if Maven would tolerate stuff it doesn't understand. It would be best if this could be done sooner rather than later. i.e., that alone would justify a 2.2 release.
Since I haven't done any of the work on 3.0 I'm not going to make a big deal out of what the version number of the release should be.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
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
Re: Maven 2.2.2 soon?
Posted by Stephen Connolly <st...@gmail.com>.
2009/12/29 Arnaud HERITIER <ah...@gmail.com>
> >
> >
> > > >
> > >
> > > I agree. The problem will be in 3.1. We'll be able to remove things
> > > deprecated in 3.0 but nothing more.
> > > We'll have to see what we'll do if we have big changes.
> > > For me the most important problem to work on (post 3.0), will be how we
> > > manage different versions of POMs and metadata. This will have an
> > important
> > > impact for our users.
> > >
> > > cheers,
> > >
> > >
> > I think this depends on what model changes we want.
> >
> > My Idea is to deploy the new version pom as a pom with a classifier and
> > co-deploy a v4.0.0 translated pom as the pom without a classifier.
> >
> > That way we can have m4 look for the pom with classifier (if missing it
> > looks for the v4.0.0 pom) everything older will only see the pom without
> a
> > classifier
> >
> > -Stephen
> >
> > P.S. I think Brian Fox had a similar idea
> >
> >
> > In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
> deploy one per version with a different classifier ?
> And what will happen when we'll do a change in a model that we cannot
> convert to 4.0.0 model? We don't deploy it ?
>
>
We deploy the dependencies as the 4.0.0 model, we strip out the parent info
and fully resolve the pom for the 4.0.0 model
For the pom with classifier, we use a scheme that allows us to plug in
extensibility so that we only need one classifer ever... we call the
classifier "build" and the pom without classifier is just for dependency
info
> Arnaud
>
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
Seriously, please focus on 3.0.
On 2009-12-30, at 1:55 AM, Paul Benedict wrote:
> Jason,
>
> Are you suggesting that the elements of the POM body might belong to
> each respective plugin? An academic example, but to get the point
> across:
>
> <project>
> <plugin:compiler>
> <execution>
> <id>default</id> ...
> <configuration>
> <target>1.4</target>
> </configuration>
> </execution>
> <execution>
> <id>another</id> ...
> <configuration>
> <target>1.5</target>
> </configuration>
> </execution>
> </plugin:compiler>
>
> <plugin:release>...</plugin:release>
> </project>
>
> Paul
>
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Paul Benedict <pb...@apache.org>.
Jason,
Are you suggesting that the elements of the POM body might belong to
each respective plugin? An academic example, but to get the point
across:
<project>
<plugin:compiler>
<execution>
<id>default</id> ...
<configuration>
<target>1.4</target>
</configuration>
</execution>
<execution>
<id>another</id> ...
<configuration>
<target>1.5</target>
</configuration>
</execution>
</plugin:compiler>
<plugin:release>...</plugin:release>
</project>
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Paul Benedict <pb...@apache.org>.
On Tue, Dec 29, 2009 at 8:30 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Dec 29, 2009, at 6:22 PM, Paul Benedict wrote:
>
>> I think Maven POMs should be like the rules governing HTML and CSS
>> versions. Ignore tags and attributes you don't know and interpret what
>> you can. Allow graceful degration of behavior so those who want to
>> publish 4.1 POMs can still be used with 4.0 readers.
>
> "Graceful degradation" doesn't work. 4.0 is strict. Maven 2.x won't handle anything undefined. The only reasonable solution is that the new project descriptor won't be a pom.xml. pom.xml will always be reserved for a 2.x compatible POM.
Unless Maven 2 is given the ability *today* to be forward compatible,
I agree, then it has no chance of being graceful. What a pity. I
believe forward-compatibility would be a great thing and the 20(?)
years of HTML specs would be valuable to learn from.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Stephen Connolly <st...@gmail.com>.
2009/12/29 Brian Fox <br...@infinity.nu>
> I 100% agree that the pom format is likely the single biggest thing we
> need to tackle in the future. What that means for future maven
> versions is unclear since I agree that pom changes would justify a
> major version bump although I don't think we want to talk about 4.x.
>
>
well it would make more sense to call it 5.x and skip 4.x entirely since the
model version is already at 4.0.0 ;-)
> However I definitely think that this version belongs as 3.x, there are
> enough changes to justify it, and the fact that it's all new code
> means we shouldn't hide it under 2.x.
>
>
> On Tue, Dec 29, 2009 at 1:24 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
> >
> >>
> >> I agree. The problem will be in 3.1. We'll be able to remove things
> >> deprecated in 3.0 but nothing more.
> >> We'll have to see what we'll do if we have big changes.
> >> For me the most important problem to work on (post 3.0), will be how we
> >> manage different versions of POMs and metadata. This will have an
> important
> >> impact for our users.
> >>
> >
> > What I recall discussing with Brian at ApacheCon was having a new project
> descriptor but making sure that when projects are installed or deployed a
> pom compatible with the current format would also be deployed along with the
> new descriptor. If the new project descriptor allows extension then this
> could continue to work as things change.
> >
> > Ralph
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Maven 2.2.2 soon?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2009, at 6:22 PM, Paul Benedict wrote:
> I think Maven POMs should be like the rules governing HTML and CSS
> versions. Ignore tags and attributes you don't know and interpret what
> you can. Allow graceful degration of behavior so those who want to
> publish 4.1 POMs can still be used with 4.0 readers.
"Graceful degradation" doesn't work. 4.0 is strict. Maven 2.x won't handle anything undefined. The only reasonable solution is that the new project descriptor won't be a pom.xml. pom.xml will always be reserved for a 2.x compatible POM.
The new project descriptor should allow for enhancement. One of the things we should discuss and agree on is how that will work. There is an advantage to having a schema for validation, but logical extension points need to be allowed. This would also be a great time to make the new descriptor less verbose.
Ralph
>
> On Tue, Dec 29, 2009 at 7:05 PM, Arnaud HERITIER <ah...@gmail.com> wrote:
>>>
>>>> What I recall discussing with Brian at ApacheCon was having a new project
>>> descriptor but making sure that when projects are installed or deployed a
>>> pom compatible with the current format would also be deployed along with the
>>> new descriptor. If the new project descriptor allows extension then this
>>> could continue to work as things change.
>>>
>>>
>>> Yah, I think we've been beating this around for a while... in my mind, it's
>>> still a unified repository metadata format that the POM translates to (and a
>>> parallel 4.0.0 POM / maven-metadata for old clients).
>>>
>>> It seems like that and the POM and the deprecations can be the single focus
>>> for 3.1... we just need to ship "Snow Maven" at this point so we can move on
>>> to new things.
>>>
>>>
>>>
>> Do we have in 3.0 a mechanism to have a constraint when we develop a plugin
>> to say that it requires a minimal version of POM.
>> Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to
>> use them, thus maven shouldn't automatically check when it load a plugin
>> that it is compatible with the POM version.
>>
>> Another question about 3.0, did we reintroduce // dowloads ? I think it
>> wasn't here in the last alpha.
>>
>> Arnaud
>>
>
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Paul Benedict <pb...@apache.org>.
I think Maven POMs should be like the rules governing HTML and CSS
versions. Ignore tags and attributes you don't know and interpret what
you can. Allow graceful degration of behavior so those who want to
publish 4.1 POMs can still be used with 4.0 readers.
On Tue, Dec 29, 2009 at 7:05 PM, Arnaud HERITIER <ah...@gmail.com> wrote:
>>
>> > What I recall discussing with Brian at ApacheCon was having a new project
>> descriptor but making sure that when projects are installed or deployed a
>> pom compatible with the current format would also be deployed along with the
>> new descriptor. If the new project descriptor allows extension then this
>> could continue to work as things change.
>>
>>
>> Yah, I think we've been beating this around for a while... in my mind, it's
>> still a unified repository metadata format that the POM translates to (and a
>> parallel 4.0.0 POM / maven-metadata for old clients).
>>
>> It seems like that and the POM and the deprecations can be the single focus
>> for 3.1... we just need to ship "Snow Maven" at this point so we can move on
>> to new things.
>>
>>
>>
> Do we have in 3.0 a mechanism to have a constraint when we develop a plugin
> to say that it requires a minimal version of POM.
> Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to
> use them, thus maven shouldn't automatically check when it load a plugin
> that it is compatible with the POM version.
>
> Another question about 3.0, did we reintroduce // dowloads ? I think it
> wasn't here in the last alpha.
>
> Arnaud
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-30, at 1:48 AM, Arnaud HERITIER wrote:
> On Wed, Dec 30, 2009 at 2:45 AM, Jason van Zyl <ja...@sonatype.com> wrote:
>
>>
>> On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote:
>>
>>>>
>>>>> What I recall discussing with Brian at ApacheCon was having a new
>> project
>>>> descriptor but making sure that when projects are installed or deployed
>> a
>>>> pom compatible with the current format would also be deployed along with
>> the
>>>> new descriptor. If the new project descriptor allows extension then this
>>>> could continue to work as things change.
>>>>
>>>>
>>>> Yah, I think we've been beating this around for a while... in my mind,
>> it's
>>>> still a unified repository metadata format that the POM translates to
>> (and a
>>>> parallel 4.0.0 POM / maven-metadata for old clients).
>>>>
>>>> It seems like that and the POM and the deprecations can be the single
>> focus
>>>> for 3.1... we just need to ship "Snow Maven" at this point so we can
>> move on
>>>> to new things.
>>>>
>>>>
>>>>
>>> Do we have in 3.0 a mechanism to have a constraint when we develop a
>> plugin
>>> to say that it requires a minimal version of POM.
>>
>> I would argue this should never happen in the future. A plugin should
>> define what it needs in its own configuration. I'm also going to push for
>> getting plugin specific POM elements back into the plugins that operate on
>> that data. Like pushing the resources elements into the resources plugin,
>> the distribution management information back into the deploy plugin, source
>> roots to the compiler plugin and anything akin to it. It's the only way to
>> continue scaling. There are changes that need to be made to the POM but I
>> really don't want to see proliferation of POM elements to service specific
>> plugins.
>>
>> I don't agree with Ralph that there needs to be a general POM extension
>> mechanism. It's going to happen primarily inside plugins.
>>
>
> ok for me to push what we can in plugins configurations but won't we have
> quickly some plugins incompatibilities because they'll share some info like
> resources, sources and many others (encoding, compiler version) and if the
> plugin which stores this info changes the name of the config or something
> like that, all others will be broken ? I wouldn't like we have again the
> maven 1 experience where plugins used others and finally we didn't control
> them !
Arnaud, seriously don't worry about it right now. Let's get 3.0 out the door and there is a ton to do just in that. Everything is the same right now, 3.0 should be a drop in replacement. Let's not get ahead of ourselves.
>
> Another thing if we move more data in plugins is the verbosity of our
> config. Even if we'll have alternative format, instead of
> overriding/extending build/resource we'll have to do it in
> build/plugins/plugin/config/resources ..... (many lines for a little
> change).
>
> To end another disadvantage to have more things in plugins config is that we
> won't validate them (with a schema and at runtime) and we'll ignore wrong
> settings which is always a big issues for our users because they don't
> quickly see if they made a misprint in the config.
>
>
>>
>>> Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to
>>> use them, thus maven shouldn't automatically check when it load a plugin
>>> that it is compatible with the POM version.
>>
>> Sure, we can augment whatever is necessary in preparation for 3.1.
>>
>>>
>>> Another question about 3.0, did we reintroduce // dowloads ? I think it
>>> wasn't here in the last alpha.
>>
>> One form of it is in the Jetty Wagon we have at Sonatype. There is a new
>> interface called the RepositorySystem which encapsulates everything with far
>> fewer interfaces then the legacy system. We also have another set of
>> interfaces which is a complete internal replacement. Benjamin has this on a
>> branch. So if someone wants to try and implement or backport Don's work then
>> that's cool too. If we want to get a 3.0 sometime around the beginning of
>> February then I'm not sure that will make it into 3.0. Might be soon after
>> that.
>>
>> I'm still more in favour IT quality, getting the JIRA issues cleaned up and
>> getting out the 3.0.
>>
>> If people want this released soonish and want specific features then speak
>> now and commit your time.
>>
>>>
>>> Arnaud
>>
>> 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
>>
>>
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
Re: Maven 2.2.2 soon?
Posted by Arnaud HERITIER <ah...@gmail.com>.
On Wed, Dec 30, 2009 at 2:45 AM, Jason van Zyl <ja...@sonatype.com> wrote:
>
> On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote:
>
> >>
> >>> What I recall discussing with Brian at ApacheCon was having a new
> project
> >> descriptor but making sure that when projects are installed or deployed
> a
> >> pom compatible with the current format would also be deployed along with
> the
> >> new descriptor. If the new project descriptor allows extension then this
> >> could continue to work as things change.
> >>
> >>
> >> Yah, I think we've been beating this around for a while... in my mind,
> it's
> >> still a unified repository metadata format that the POM translates to
> (and a
> >> parallel 4.0.0 POM / maven-metadata for old clients).
> >>
> >> It seems like that and the POM and the deprecations can be the single
> focus
> >> for 3.1... we just need to ship "Snow Maven" at this point so we can
> move on
> >> to new things.
> >>
> >>
> >>
> > Do we have in 3.0 a mechanism to have a constraint when we develop a
> plugin
> > to say that it requires a minimal version of POM.
>
> I would argue this should never happen in the future. A plugin should
> define what it needs in its own configuration. I'm also going to push for
> getting plugin specific POM elements back into the plugins that operate on
> that data. Like pushing the resources elements into the resources plugin,
> the distribution management information back into the deploy plugin, source
> roots to the compiler plugin and anything akin to it. It's the only way to
> continue scaling. There are changes that need to be made to the POM but I
> really don't want to see proliferation of POM elements to service specific
> plugins.
>
> I don't agree with Ralph that there needs to be a general POM extension
> mechanism. It's going to happen primarily inside plugins.
>
ok for me to push what we can in plugins configurations but won't we have
quickly some plugins incompatibilities because they'll share some info like
resources, sources and many others (encoding, compiler version) and if the
plugin which stores this info changes the name of the config or something
like that, all others will be broken ? I wouldn't like we have again the
maven 1 experience where plugins used others and finally we didn't control
them !
Another thing if we move more data in plugins is the verbosity of our
config. Even if we'll have alternative format, instead of
overriding/extending build/resource we'll have to do it in
build/plugins/plugin/config/resources ..... (many lines for a little
change).
To end another disadvantage to have more things in plugins config is that we
won't validate them (with a schema and at runtime) and we'll ignore wrong
settings which is always a big issues for our users because they don't
quickly see if they made a misprint in the config.
>
> > Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to
> > use them, thus maven shouldn't automatically check when it load a plugin
> > that it is compatible with the POM version.
>
> Sure, we can augment whatever is necessary in preparation for 3.1.
>
> >
> > Another question about 3.0, did we reintroduce // dowloads ? I think it
> > wasn't here in the last alpha.
>
> One form of it is in the Jetty Wagon we have at Sonatype. There is a new
> interface called the RepositorySystem which encapsulates everything with far
> fewer interfaces then the legacy system. We also have another set of
> interfaces which is a complete internal replacement. Benjamin has this on a
> branch. So if someone wants to try and implement or backport Don's work then
> that's cool too. If we want to get a 3.0 sometime around the beginning of
> February then I'm not sure that will make it into 3.0. Might be soon after
> that.
>
> I'm still more in favour IT quality, getting the JIRA issues cleaned up and
> getting out the 3.0.
>
> If people want this released soonish and want specific features then speak
> now and commit your time.
>
> >
> > Arnaud
>
> 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
>
>
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-30, at 1:03 PM, Jason van Zyl wrote:
>
> On 2009-12-30, at 12:03 PM, Ralph Goers wrote:
>
>> I don't know why you are trying to shut off this discussion.
>>
>
> I am busy trying to do work that's necessary for 3.0.
>
>> Of course we realize 3.0 is what it is.
>
> No, I don't think you do. If you did you would be helping more with 3.0 instead of trying to discuss beyond it. I'm just going to bite my tongue as I don't think what I would say to you would be very constructive.
>
> You want a model of how things should work, look at what Dan and Kristian did with the parallelization.
>
Here I also should have added that what Olivier is doing with the site plugin is extremely helpful. He just stepped in and started working on it. We didn't need to have a massive email exchange to get that going either. Ask some questions, talk to someone on IRC (oh no!, not IRC!) and start working. It's that simple.
>> I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained.
>>
>
> Then you can figure that out with the rest of the users. I don't know what to tell you. You make me just want to give up on the Maven committers and the Maven PMC in general. You don't think the ITs that have been added, the plugin tests, the performance framework, fixing embedding are not critical for any sort of meaningful future of the project? What has been gained? Are you kidding? Try and look beyond what you want to do.
>
>> Ralph
>>
>> On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote:
>>
>>> Same thing, please focus on 3.0.
>>>
>>> On 2009-12-30, at 3:22 AM, Ralph Goers wrote:
>>>
>>>>
>>>> On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote:
>>>>>
>>>>>
>>>>> I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
>>>>>
>>>>
>>>> So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough.
>>>>
>>>> I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be.
>>>>
>>>> And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner.
>>>>
>>>>
>>>> Here is an example of what I am talking about.
>>>>
>>>> The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided.
>>>>
>>>>
>>>> <project groupId="org.apache.commons" artifactId="commons-logging" version="1.2">
>>>> <provides>
>>>> <provide id="commons-logging-api" version="1.1"/>
>>>> <provide id="commons-logging-api" version="1.2"/>
>>>> </provides>
>>>> </project>
>>>>
>>>> <project groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0">
>>>> <provides>
>>>> <provide id="commons-logging-api" version="1.1"/>
>>>> </provides>
>>>> </project>
>>>>
>>>> <project groupId="com.mycorp.test" artifactId="myapp" version="1.0">
>>>> <dependencyManagement>
>>>> <dependencies>
>>>> <dependency groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0"/>
>>>> </dependencies>
>>>> </dependencyManagement>
>>>> <dependencies>
>>>> <requires id="org.springsource.spring-core">
>>>> <version compare="ge">3.1</version>
>>>> </requires>
>>>> <dependencies>
>>>> </project>
>>>>
>>>> <project groupId="org.springsource" artifactId="spring-core" version="3.1">
>>>> <dependencyManagement>
>>>> <dependencies>
>>>> <dependency groupId="org.apache.commons" artifactId="commons-logging" version="1.2"/>
>>>> </dependencies>
>>>> </dependencyManagement> <depencencies>
>>>> <requires id="commons-logging-api" version="1.1"/>
>>>> </dependencies>
>>>> </project>
>>>
>>> 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
>
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
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-30, at 12:03 PM, Ralph Goers wrote:
> I don't know why you are trying to shut off this discussion.
>
I am busy trying to do work that's necessary for 3.0.
> Of course we realize 3.0 is what it is.
No, I don't think you do. If you did you would be helping more with 3.0 instead of trying to discuss beyond it. I'm just going to bite my tongue as I don't think what I would say to you would be very constructive.
You want a model of how things should work, look at what Dan and Kristian did with the parallelization.
> I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained.
>
Then you can figure that out with the rest of the users. I don't know what to tell you. You make me just want to give up on the Maven committers and the Maven PMC in general. You don't think the ITs that have been added, the plugin tests, the performance framework, fixing embedding are not critical for any sort of meaningful future of the project? What has been gained? Are you kidding? Try and look beyond what you want to do.
> Ralph
>
> On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote:
>
>> Same thing, please focus on 3.0.
>>
>> On 2009-12-30, at 3:22 AM, Ralph Goers wrote:
>>
>>>
>>> On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote:
>>>>
>>>>
>>>> I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
>>>>
>>>
>>> So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough.
>>>
>>> I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be.
>>>
>>> And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner.
>>>
>>>
>>> Here is an example of what I am talking about.
>>>
>>> The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided.
>>>
>>>
>>> <project groupId="org.apache.commons" artifactId="commons-logging" version="1.2">
>>> <provides>
>>> <provide id="commons-logging-api" version="1.1"/>
>>> <provide id="commons-logging-api" version="1.2"/>
>>> </provides>
>>> </project>
>>>
>>> <project groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0">
>>> <provides>
>>> <provide id="commons-logging-api" version="1.1"/>
>>> </provides>
>>> </project>
>>>
>>> <project groupId="com.mycorp.test" artifactId="myapp" version="1.0">
>>> <dependencyManagement>
>>> <dependencies>
>>> <dependency groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0"/>
>>> </dependencies>
>>> </dependencyManagement>
>>> <dependencies>
>>> <requires id="org.springsource.spring-core">
>>> <version compare="ge">3.1</version>
>>> </requires>
>>> <dependencies>
>>> </project>
>>>
>>> <project groupId="org.springsource" artifactId="spring-core" version="3.1">
>>> <dependencyManagement>
>>> <dependencies>
>>> <dependency groupId="org.apache.commons" artifactId="commons-logging" version="1.2"/>
>>> </dependencies>
>>> </dependencyManagement> <depencencies>
>>> <requires id="commons-logging-api" version="1.1"/>
>>> </dependencies>
>>> </project>
>>
>> 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
RE: Maven 2.2.2 soon?
Posted by "Clark, Gil W." <Gi...@intuit.com>.
Seems like you are looking for an osgi sort of function?
-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
Sent: Wednesday, December 30, 2009 9:03 AM
To: Maven Developers List
Subject: Re: Maven 2.2.2 soon?
I don't know why you are trying to shut off this discussion.
Of course we realize 3.0 is what it is. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained.
Ralph
On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote:
> Same thing, please focus on 3.0.
>
> On 2009-12-30, at 3:22 AM, Ralph Goers wrote:
>
>>
>> On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote:
>>>
>>>
>>> I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
>>>
>>
>> So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough.
>>
>> I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be.
>>
>> And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner.
>>
>>
>> Here is an example of what I am talking about.
>>
>> The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided.
>>
>>
>> <project groupId="org.apache.commons" artifactId="commons-logging" version="1.2">
>> <provides>
>> <provide id="commons-logging-api" version="1.1"/>
>> <provide id="commons-logging-api" version="1.2"/>
>> </provides>
>> </project>
>>
>> <project groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0">
>> <provides>
>> <provide id="commons-logging-api" version="1.1"/>
>> </provides>
>> </project>
>>
>> <project groupId="com.mycorp.test" artifactId="myapp" version="1.0">
>> <dependencyManagement>
>> <dependencies>
>> <dependency groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0"/>
>> </dependencies>
>> </dependencyManagement>
>> <dependencies>
>> <requires id="org.springsource.spring-core">
>> <version compare="ge">3.1</version>
>> </requires>
>> <dependencies>
>> </project>
>>
>> <project groupId="org.springsource" artifactId="spring-core" version="3.1">
>> <dependencyManagement>
>> <dependencies>
>> <dependency groupId="org.apache.commons" artifactId="commons-logging" version="1.2"/>
>> </dependencies>
>> </dependencyManagement> <depencencies>
>> <requires id="commons-logging-api" version="1.1"/>
>> </dependencies>
>> </project>
>
> 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
Re: Maven 2.2.2 soon?
Posted by Ralph Goers <ra...@dslextreme.com>.
I don't know why you are trying to shut off this discussion.
Of course we realize 3.0 is what it is. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained.
Ralph
On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote:
> Same thing, please focus on 3.0.
>
> On 2009-12-30, at 3:22 AM, Ralph Goers wrote:
>
>>
>> On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote:
>>>
>>>
>>> I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
>>>
>>
>> So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough.
>>
>> I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be.
>>
>> And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner.
>>
>>
>> Here is an example of what I am talking about.
>>
>> The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided.
>>
>>
>> <project groupId="org.apache.commons" artifactId="commons-logging" version="1.2">
>> <provides>
>> <provide id="commons-logging-api" version="1.1"/>
>> <provide id="commons-logging-api" version="1.2"/>
>> </provides>
>> </project>
>>
>> <project groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0">
>> <provides>
>> <provide id="commons-logging-api" version="1.1"/>
>> </provides>
>> </project>
>>
>> <project groupId="com.mycorp.test" artifactId="myapp" version="1.0">
>> <dependencyManagement>
>> <dependencies>
>> <dependency groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0"/>
>> </dependencies>
>> </dependencyManagement>
>> <dependencies>
>> <requires id="org.springsource.spring-core">
>> <version compare="ge">3.1</version>
>> </requires>
>> <dependencies>
>> </project>
>>
>> <project groupId="org.springsource" artifactId="spring-core" version="3.1">
>> <dependencyManagement>
>> <dependencies>
>> <dependency groupId="org.apache.commons" artifactId="commons-logging" version="1.2"/>
>> </dependencies>
>> </dependencyManagement> <depencencies>
>> <requires id="commons-logging-api" version="1.1"/>
>> </dependencies>
>> </project>
>
> 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
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
Same thing, please focus on 3.0.
On 2009-12-30, at 3:22 AM, Ralph Goers wrote:
>
> On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote:
>>
>>
>> I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
>>
>
> So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough.
>
> I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be.
>
> And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner.
>
>
> Here is an example of what I am talking about.
>
> The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided.
>
>
> <project groupId="org.apache.commons" artifactId="commons-logging" version="1.2">
> <provides>
> <provide id="commons-logging-api" version="1.1"/>
> <provide id="commons-logging-api" version="1.2"/>
> </provides>
> </project>
>
> <project groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0">
> <provides>
> <provide id="commons-logging-api" version="1.1"/>
> </provides>
> </project>
>
> <project groupId="com.mycorp.test" artifactId="myapp" version="1.0">
> <dependencyManagement>
> <dependencies>
> <dependency groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0"/>
> </dependencies>
> </dependencyManagement>
> <dependencies>
> <requires id="org.springsource.spring-core">
> <version compare="ge">3.1</version>
> </requires>
> <dependencies>
> </project>
>
> <project groupId="org.springsource" artifactId="spring-core" version="3.1">
> <dependencyManagement>
> <dependencies>
> <dependency groupId="org.apache.commons" artifactId="commons-logging" version="1.2"/>
> </dependencies>
> </dependencyManagement> <depencencies>
> <requires id="commons-logging-api" version="1.1"/>
> </dependencies>
> </project>
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
Re: Maven 2.2.2 soon?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote:
>
>
> I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
>
So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough.
I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be.
And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner.
Here is an example of what I am talking about.
The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided.
<project groupId="org.apache.commons" artifactId="commons-logging" version="1.2">
<provides>
<provide id="commons-logging-api" version="1.1"/>
<provide id="commons-logging-api" version="1.2"/>
</provides>
</project>
<project groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0">
<provides>
<provide id="commons-logging-api" version="1.1"/>
</provides>
</project>
<project groupId="com.mycorp.test" artifactId="myapp" version="1.0">
<dependencyManagement>
<dependencies>
<dependency groupId="org.slf4j" artifactId="jcl-over-slf4j" version="2.0"/>
</dependencies>
</dependencyManagement>
<dependencies>
<requires id="org.springsource.spring-core">
<version compare="ge">3.1</version>
</requires>
<dependencies>
</project>
<project groupId="org.springsource" artifactId="spring-core" version="3.1">
<dependencyManagement>
<dependencies>
<dependency groupId="org.apache.commons" artifactId="commons-logging" version="1.2"/>
</dependencies>
</dependencyManagement> <depencencies>
<requires id="commons-logging-api" version="1.1"/>
</dependencies>
</project>
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote:
>>
>>> What I recall discussing with Brian at ApacheCon was having a new project
>> descriptor but making sure that when projects are installed or deployed a
>> pom compatible with the current format would also be deployed along with the
>> new descriptor. If the new project descriptor allows extension then this
>> could continue to work as things change.
>>
>>
>> Yah, I think we've been beating this around for a while... in my mind, it's
>> still a unified repository metadata format that the POM translates to (and a
>> parallel 4.0.0 POM / maven-metadata for old clients).
>>
>> It seems like that and the POM and the deprecations can be the single focus
>> for 3.1... we just need to ship "Snow Maven" at this point so we can move on
>> to new things.
>>
>>
>>
> Do we have in 3.0 a mechanism to have a constraint when we develop a plugin
> to say that it requires a minimal version of POM.
I would argue this should never happen in the future. A plugin should define what it needs in its own configuration. I'm also going to push for getting plugin specific POM elements back into the plugins that operate on that data. Like pushing the resources elements into the resources plugin, the distribution management information back into the deploy plugin, source roots to the compiler plugin and anything akin to it. It's the only way to continue scaling. There are changes that need to be made to the POM but I really don't want to see proliferation of POM elements to service specific plugins.
I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins.
> Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to
> use them, thus maven shouldn't automatically check when it load a plugin
> that it is compatible with the POM version.
Sure, we can augment whatever is necessary in preparation for 3.1.
>
> Another question about 3.0, did we reintroduce // dowloads ? I think it
> wasn't here in the last alpha.
One form of it is in the Jetty Wagon we have at Sonatype. There is a new interface called the RepositorySystem which encapsulates everything with far fewer interfaces then the legacy system. We also have another set of interfaces which is a complete internal replacement. Benjamin has this on a branch. So if someone wants to try and implement or backport Don's work then that's cool too. If we want to get a 3.0 sometime around the beginning of February then I'm not sure that will make it into 3.0. Might be soon after that.
I'm still more in favour IT quality, getting the JIRA issues cleaned up and getting out the 3.0.
If people want this released soonish and want specific features then speak now and commit your time.
>
> Arnaud
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
Re: Maven 2.2.2 soon?
Posted by Arnaud HERITIER <ah...@gmail.com>.
>
> > What I recall discussing with Brian at ApacheCon was having a new project
> descriptor but making sure that when projects are installed or deployed a
> pom compatible with the current format would also be deployed along with the
> new descriptor. If the new project descriptor allows extension then this
> could continue to work as things change.
>
>
> Yah, I think we've been beating this around for a while... in my mind, it's
> still a unified repository metadata format that the POM translates to (and a
> parallel 4.0.0 POM / maven-metadata for old clients).
>
> It seems like that and the POM and the deprecations can be the single focus
> for 3.1... we just need to ship "Snow Maven" at this point so we can move on
> to new things.
>
>
>
Do we have in 3.0 a mechanism to have a constraint when we develop a plugin
to say that it requires a minimal version of POM.
Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to
use them, thus maven shouldn't automatically check when it load a plugin
that it is compatible with the POM version.
Another question about 3.0, did we reintroduce // dowloads ? I think it
wasn't here in the last alpha.
Arnaud
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
On 30/12/2009, at 5:24 AM, Ralph Goers wrote:
>
> On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
>
>>
>> I agree. The problem will be in 3.1. We'll be able to remove things
>> deprecated in 3.0 but nothing more.
>> We'll have to see what we'll do if we have big changes.
>> For me the most important problem to work on (post 3.0), will be how we
>> manage different versions of POMs and metadata. This will have an important
>> impact for our users.
>>
>
> What I recall discussing with Brian at ApacheCon was having a new project descriptor but making sure that when projects are installed or deployed a pom compatible with the current format would also be deployed along with the new descriptor. If the new project descriptor allows extension then this could continue to work as things change.
Yah, I think we've been beating this around for a while... in my mind, it's still a unified repository metadata format that the POM translates to (and a parallel 4.0.0 POM / maven-metadata for old clients).
It seems like that and the POM and the deprecations can be the single focus for 3.1... we just need to ship "Snow Maven" at this point so we can move on to new things.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Brian Fox <br...@infinity.nu>.
I 100% agree that the pom format is likely the single biggest thing we
need to tackle in the future. What that means for future maven
versions is unclear since I agree that pom changes would justify a
major version bump although I don't think we want to talk about 4.x.
However I definitely think that this version belongs as 3.x, there are
enough changes to justify it, and the fact that it's all new code
means we shouldn't hide it under 2.x.
On Tue, Dec 29, 2009 at 1:24 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
>
>>
>> I agree. The problem will be in 3.1. We'll be able to remove things
>> deprecated in 3.0 but nothing more.
>> We'll have to see what we'll do if we have big changes.
>> For me the most important problem to work on (post 3.0), will be how we
>> manage different versions of POMs and metadata. This will have an important
>> impact for our users.
>>
>
> What I recall discussing with Brian at ApacheCon was having a new project descriptor but making sure that when projects are installed or deployed a pom compatible with the current format would also be deployed along with the new descriptor. If the new project descriptor allows extension then this could continue to work as things change.
>
> Ralph
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
>
> I agree. The problem will be in 3.1. We'll be able to remove things
> deprecated in 3.0 but nothing more.
> We'll have to see what we'll do if we have big changes.
> For me the most important problem to work on (post 3.0), will be how we
> manage different versions of POMs and metadata. This will have an important
> impact for our users.
>
What I recall discussing with Brian at ApacheCon was having a new project descriptor but making sure that when projects are installed or deployed a pom compatible with the current format would also be deployed along with the new descriptor. If the new project descriptor allows extension then this could continue to work as things change.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Arnaud HERITIER <ar...@exoplatform.com>.
On Tuesday, December 29, 2009, Jason van Zyl <ja...@sonatype.com> wrote:
>
> On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote:
>
>>>
>>>
>>>>>
>>>>
>>>> I agree. The problem will be in 3.1. We'll be able to remove things
>>>> deprecated in 3.0 but nothing more.
>>>> We'll have to see what we'll do if we have big changes.
>>>> For me the most important problem to work on (post 3.0), will be how we
>>>> manage different versions of POMs and metadata. This will have an
>>> important
>>>> impact for our users.
>>>>
>>>> cheers,
>>>>
>>>>
>>> I think this depends on what model changes we want.
>>>
>>> My Idea is to deploy the new version pom as a pom with a classifier and
>>> co-deploy a v4.0.0 translated pom as the pom without a classifier.
>>>
>>> That way we can have m4 look for the pom with classifier (if missing it
>>> looks for the v4.0.0 pom) everything older will only see the pom without a
>>> classifier
>>>
>>> -Stephen
>>>
>>> P.S. I think Brian Fox had a similar idea
>>>
>>>
>>> In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
>> deploy one per version with a different classifier ?
>> And what will happen when we'll do a change in a model that we cannot
>> convert to 4.0.0 model? We don't deploy it ?
>>
>
> Trust me, we'll be talking about this for a while. If it's simply binary consumption it's the dependencies that matter and the 4.0.0 of the POM can probably be used forever, that's not really a big deal. But I think we have to take a larger view here with respect to projects that want to rebuild projects from source, integrating 3rd party tools, and syncing this up with metadata changes that might happen in the repository.
>
> But I really think this is going to be done in a branching by abstraction fashion and it's just all going to have to work in the trunk. We just can't ever afford to go off into branches because this developer community cannot support it.
>
I trust you ;). I'm just doing the advocate of devil.
For dependencies I agree it is easy. But not too easy. We already
broke backward compat with the import scope in 2.0.9
I think the problem will be more for inheritence (and perhaps mixins) ?
>> Arnaud
>
> 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
>
>
--
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote:
>>
>>
>>>>
>>>
>>> I agree. The problem will be in 3.1. We'll be able to remove things
>>> deprecated in 3.0 but nothing more.
>>> We'll have to see what we'll do if we have big changes.
>>> For me the most important problem to work on (post 3.0), will be how we
>>> manage different versions of POMs and metadata. This will have an
>> important
>>> impact for our users.
>>>
>>> cheers,
>>>
>>>
>> I think this depends on what model changes we want.
>>
>> My Idea is to deploy the new version pom as a pom with a classifier and
>> co-deploy a v4.0.0 translated pom as the pom without a classifier.
>>
>> That way we can have m4 look for the pom with classifier (if missing it
>> looks for the v4.0.0 pom) everything older will only see the pom without a
>> classifier
>>
>> -Stephen
>>
>> P.S. I think Brian Fox had a similar idea
>>
>>
>> In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
> deploy one per version with a different classifier ?
> And what will happen when we'll do a change in a model that we cannot
> convert to 4.0.0 model? We don't deploy it ?
>
Trust me, we'll be talking about this for a while. If it's simply binary consumption it's the dependencies that matter and the 4.0.0 of the POM can probably be used forever, that's not really a big deal. But I think we have to take a larger view here with respect to projects that want to rebuild projects from source, integrating 3rd party tools, and syncing this up with metadata changes that might happen in the repository.
But I really think this is going to be done in a branching by abstraction fashion and it's just all going to have to work in the trunk. We just can't ever afford to go off into branches because this developer community cannot support it.
> Arnaud
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
Re: Maven 2.2.2 soon?
Posted by Arnaud HERITIER <ah...@gmail.com>.
>
>
> > >
> >
> > I agree. The problem will be in 3.1. We'll be able to remove things
> > deprecated in 3.0 but nothing more.
> > We'll have to see what we'll do if we have big changes.
> > For me the most important problem to work on (post 3.0), will be how we
> > manage different versions of POMs and metadata. This will have an
> important
> > impact for our users.
> >
> > cheers,
> >
> >
> I think this depends on what model changes we want.
>
> My Idea is to deploy the new version pom as a pom with a classifier and
> co-deploy a v4.0.0 translated pom as the pom without a classifier.
>
> That way we can have m4 look for the pom with classifier (if missing it
> looks for the v4.0.0 pom) everything older will only see the pom without a
> classifier
>
> -Stephen
>
> P.S. I think Brian Fox had a similar idea
>
>
> In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to
deploy one per version with a different classifier ?
And what will happen when we'll do a change in a model that we cannot
convert to 4.0.0 model? We don't deploy it ?
Arnaud
Re: Maven 2.2.2 soon?
Posted by Stephen Connolly <st...@gmail.com>.
2009/12/29 Arnaud HERITIER <ah...@gmail.com>
> On Tue, Dec 29, 2009 at 4:24 PM, Brett Porter <br...@apache.org> wrote:
>
> >
> > On 29/12/2009, at 8:18 PM, 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.
> >
> > I tend to agree, but I think the target has moved so much, especially
> with
> > a lot of public talks about the versions, that changing anything might
> cause
> > further confusion.
> >
>
> yes. it's impossible to change.
>
>
> >
> > What about something like this:
> > - 2.3 (or 2.9?) release that just adds all the deprecations (kind of like
> > what Lucene did before a major rev).
> > - 3.0 release retains deprecated functionality, with a --strict mode to
> > fail instead of warning (I haven't seen this, but ISTR Brian saying this
> was
> > going to be added, or is already there, at ApacheCon)
> > - 3.1 can then drop the functionality
> >
> > So, 3.0 essentially drops the functionality, with a "grace period" -
> which
> > is closer to what users might expect without changing the current story.
> >
>
> +1, with the strict mode activated by default in 3.0. We could have an
> option in settings.xml to deactivate it for example.
>
> >
> > WDYT?
> >
>
> I agree. The problem will be in 3.1. We'll be able to remove things
> deprecated in 3.0 but nothing more.
> We'll have to see what we'll do if we have big changes.
> For me the most important problem to work on (post 3.0), will be how we
> manage different versions of POMs and metadata. This will have an important
> impact for our users.
>
> cheers,
>
>
I think this depends on what model changes we want.
My Idea is to deploy the new version pom as a pom with a classifier and
co-deploy a v4.0.0 translated pom as the pom without a classifier.
That way we can have m4 look for the pom with classifier (if missing it
looks for the v4.0.0 pom) everything older will only see the pom without a
classifier
-Stephen
P.S. I think Brian Fox had a similar idea
> >
> > - Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 2.2.2 soon?
Posted by Arnaud HERITIER <ah...@gmail.com>.
On Tue, Dec 29, 2009 at 4:24 PM, Brett Porter <br...@apache.org> wrote:
>
> On 29/12/2009, at 8:18 PM, 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.
>
> I tend to agree, but I think the target has moved so much, especially with
> a lot of public talks about the versions, that changing anything might cause
> further confusion.
>
yes. it's impossible to change.
>
> What about something like this:
> - 2.3 (or 2.9?) release that just adds all the deprecations (kind of like
> what Lucene did before a major rev).
> - 3.0 release retains deprecated functionality, with a --strict mode to
> fail instead of warning (I haven't seen this, but ISTR Brian saying this was
> going to be added, or is already there, at ApacheCon)
> - 3.1 can then drop the functionality
>
> So, 3.0 essentially drops the functionality, with a "grace period" - which
> is closer to what users might expect without changing the current story.
>
+1, with the strict mode activated by default in 3.0. We could have an
option in settings.xml to deactivate it for example.
>
> WDYT?
>
I agree. The problem will be in 3.1. We'll be able to remove things
deprecated in 3.0 but nothing more.
We'll have to see what we'll do if we have big changes.
For me the most important problem to work on (post 3.0), will be how we
manage different versions of POMs and metadata. This will have an important
impact for our users.
cheers,
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
On 29/12/2009, at 8:18 PM, 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.
I tend to agree, but I think the target has moved so much, especially with a lot of public talks about the versions, that changing anything might cause further confusion.
What about something like this:
- 2.3 (or 2.9?) release that just adds all the deprecations (kind of like what Lucene did before a major rev).
- 3.0 release retains deprecated functionality, with a --strict mode to fail instead of warning (I haven't seen this, but ISTR Brian saying this was going to be added, or is already there, at ApacheCon)
- 3.1 can then drop the functionality
So, 3.0 essentially drops the functionality, with a "grace period" - which is closer to what users might expect without changing the current story.
WDYT?
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
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 <ra...@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-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
Re: Maven 2.2.2 soon?
Posted by Mark Struberg <st...@yahoo.de>.
I think 3.0 is ok.
True, a lot projects may run out of the box without migration. But we do not guarantee that! Thus a 2.x number would be misleading. The '3.0' will make users aware that they might have to tweak their builds slightly.
Otoh, all compatibility features wie take over to 3.0 (and not explicitly stating it's deprectation status) will become a lot harder to remove in 3.1.
just my .02
LieGrue,
strub
--- On Tue, 12/29/09, Arnaud HERITIER <ah...@gmail.com> wrote:
> From: Arnaud HERITIER <ah...@gmail.com>
> Subject: Re: Maven 2.2.2 soon?
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Tuesday, December 29, 2009, 10:18 AM
> +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 <ra...@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-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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Arnaud HERITIER <ah...@gmail.com>.
+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 <ra...@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-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
>
>
Re: Maven 2.2.2 soon?
Posted by Ralph Goers <ra...@dslextreme.com>.
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-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
Re: Maven 2.2.2 soon?
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my [rhymes with tryPod] ;-)
On 29 Dec 2009, at 05:49, Jason van Zyl <ja...@sonatype.com> wrote:
> There are 511 issues left if you exclude the documentation fix
> version. Call it 30 minutes an issue on average and that's ~250 man
> hours. If we could get 10 people in January to do 25 hours (which is
> a lot for most people) and try and make it easier for users to
> validate fixes we might be able to pull it off in January.
>
between my son and his sleep deprevation torture that he is
delivering ( I connfess, son, it was I who conspired with your mother
to bring you into this world! ) and work commitments, I do not think I
will have availability before feb
- Stephen
> http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143&fixfor=14504&fixfor=16088&fixfor=16089&fixfor=14118&fixfor=16090&fixfor=16087&fixfor=15103&fixfor=16094&fixfor=16093&fixfor=15565&fixfor=15472&fixfor=15554&fixfor=13145&fixfor=13142&fixfor=13141&fixfor=15996&fixfor=14593&pid=10500&status=1&status=3&status=4&reset=true&show=View+%26gt%3B%26gt%3B
>
> On 2009-12-29, at 12:12 AM, 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
>>
>
> 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
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-12-29, at 10:33 AM, Brett Porter wrote:
>
> On 29/12/2009, at 4:49 PM, Jason van Zyl wrote:
>
>> There are 511 issues left if you exclude the documentation fix version. Call it 30 minutes an issue on average and that's ~250 man hours. If we could get 10 people in January to do 25 hours (which is a lot for most people) and try and make it easier for users to validate fixes we might be able to pull it off in January.
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143&fixfor=14504&fixfor=16088&fixfor=16089&fixfor=14118&fixfor=16090&fixfor=16087&fixfor=15103&fixfor=16094&fixfor=16093&fixfor=15565&fixfor=15472&fixfor=15554&fixfor=13145&fixfor=13142&fixfor=13141&fixfor=15996&fixfor=14593&pid=10500&status=1&status=3&status=4&reset=true&show=View+%26gt%3B%26gt%3B
>>
>
> I tend to work through the "unscheduled" issues every now and then, since it makes it easier to find the new stuff that comes in. I can focus on starting there.
>
> I've liked having a "Backlog" version for things that are reviewed and may be fixed in the future, without committing to a version/series. Could we create that to start pushing valid issues into so they don't get reviewed twice? The goal is then to get rid of the *.x versions. Alternatively we could just unschedule them all and push them to the 3.x bucket.
>
> The criteria being:
> - regressions in 2.1.x/2.2.x -> 2.2.2
> - regressions in 3.0-alpha-X -> 3.0-alpha-7
> - very select number new features and improvements -> 3.1
> - everything else that is still valid -> Backlog
>
> Right?
>
Whatever you guys are going to fix in 2.x.x keep it in those versions. If you're not then flush them forward into 3.x so that we can start validating them against 3.0 to see if they are fixed or truly need to be addressed.
Anything requiring POM changes that look reasonably interesting I've been putting in 3.0.alpha1.
But in all honesty we should get down to less then 50 issues or we're never going to be able to manage them.
I think just trying to validate what's there against the 3.0 alphas will get rid of a lot of cruft. I think if we start there we'll be in good shape.
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
On 29/12/2009, at 4:49 PM, Jason van Zyl wrote:
> There are 511 issues left if you exclude the documentation fix version. Call it 30 minutes an issue on average and that's ~250 man hours. If we could get 10 people in January to do 25 hours (which is a lot for most people) and try and make it easier for users to validate fixes we might be able to pull it off in January.
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143&fixfor=14504&fixfor=16088&fixfor=16089&fixfor=14118&fixfor=16090&fixfor=16087&fixfor=15103&fixfor=16094&fixfor=16093&fixfor=15565&fixfor=15472&fixfor=15554&fixfor=13145&fixfor=13142&fixfor=13141&fixfor=15996&fixfor=14593&pid=10500&status=1&status=3&status=4&reset=true&show=View+%26gt%3B%26gt%3B
>
I tend to work through the "unscheduled" issues every now and then, since it makes it easier to find the new stuff that comes in. I can focus on starting there.
I've liked having a "Backlog" version for things that are reviewed and may be fixed in the future, without committing to a version/series. Could we create that to start pushing valid issues into so they don't get reviewed twice? The goal is then to get rid of the *.x versions. Alternatively we could just unschedule them all and push them to the 3.x bucket.
The criteria being:
- regressions in 2.1.x/2.2.x -> 2.2.2
- regressions in 3.0-alpha-X -> 3.0-alpha-7
- very select number new features and improvements -> 3.1
- everything else that is still valid -> Backlog
Right?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
There are 511 issues left if you exclude the documentation fix version. Call it 30 minutes an issue on average and that's ~250 man hours. If we could get 10 people in January to do 25 hours (which is a lot for most people) and try and make it easier for users to validate fixes we might be able to pull it off in January.
http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143&fixfor=14504&fixfor=16088&fixfor=16089&fixfor=14118&fixfor=16090&fixfor=16087&fixfor=15103&fixfor=16094&fixfor=16093&fixfor=15565&fixfor=15472&fixfor=15554&fixfor=13145&fixfor=13142&fixfor=13141&fixfor=15996&fixfor=14593&pid=10500&status=1&status=3&status=4&reset=true&show=View+%26gt%3B%26gt%3B
On 2009-12-29, at 12:12 AM, 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
>
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
Re: Maven 2.2.2 soon?
Posted by Jason van Zyl <ja...@sonatype.com>.
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
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
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.
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. 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.
For example, where are the issues that reflect switching to Guice and OSGi that we keep hearing about? 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'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 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.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Brian Fox <br...@infinity.nu>.
Is there anything pressing that calls for a 2.2.2? The 3.0's are
moving along and are quite usable.
On Mon, Dec 28, 2009 at 8:12 PM, Brett Porter <br...@apache.org> wrote:
> John, anything happening here, or reasons not to move forward with releasing? I could probably help after 2.0.11 is done.
>
> On 26/12/2009, at 9:34 PM, Paul Benedict wrote:
>
>> I know the drive for 3.0-alphas are on, and 2.0.10 is baking for a
>> release. Will 2.2.2 be revisited soon? If nothing is pressing, well,
>> that's alright too.
>>
>> Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Maven 2.2.2 soon?
Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:
> [...] or reasons not to move forward with releasing?
The changes for MNG-4148, see [0] for the former discussion.
Benjamin
[0] http://www.mail-archive.com/dev@maven.apache.org/msg82166.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 2.2.2 soon?
Posted by Brett Porter <br...@apache.org>.
John, anything happening here, or reasons not to move forward with releasing? I could probably help after 2.0.11 is done.
On 26/12/2009, at 9:34 PM, Paul Benedict wrote:
> I know the drive for 3.0-alphas are on, and 2.0.10 is baking for a
> release. Will 2.2.2 be revisited soon? If nothing is pressing, well,
> that's alright too.
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org