Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl-2]

Hi,

We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.

The first are the Guice changes that we've been talking about for a while, and the second is the introduction of Aether which is our second attempt at a stand-alone repository API. The PMC is aware of Aether as Brian reported it in our quarterly report to the Apache Board, but other developers who are not on the PMC and the community in general might not know much about it.

I just posted an entry giving a very high level description:

http://www.sonatype.com/people/2010/08/introducing-aether/

There is a resources section at the bottom of the post for those interested in the sources, issue tracking, wiki and mailing lists. As part of some of the research we are about to embark on with Daniel Le Berre, Aether will likely look more like p2 as time passes and as a final resting place the Eclipse Foundation is more likely then Apache. I know people will ask so I'm answering that now. Sonatype is just about to fully move Tycho over the Eclipse Foundation and we want to see how that goes. If that works, then M2Eclipse is next, and then Aether will follow.

At any rate we would like to merge these changes in and make plans to release 3.0-beta-2.

So please let us know if you have any objections.

Thanks,

Jason

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

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

[Benjamin Bentmann]

Jason van Zyl wrote:

> At any rate we would like to merge these changes in and make plans to release 3.0-beta-2.

Just in case, those changes currently live at
http://github.com/bentmann/maven-3/


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Olivier Lamy]

Hi,
No particular objections.
The site plugin branch for maven 3 now fail. (I haven't time to debug it more).
After the merge, how long will we have to add some "hack" to make it work ?

2010/8/3 Benjamin Bentmann <[hidden email]>:

> Jason van Zyl wrote:
>
>> At any rate we would like to merge these changes in and make plans to
>> release 3.0-beta-2.
>
> Just in case, those changes currently live at
> http://github.com/bentmann/maven-3/
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jason van Zyl-2]

On Aug 3, 2010, at 3:20 PM, Olivier Lamy wrote:

> Hi,
> No particular objections.
> The site plugin branch for maven 3 now fail. (I haven't time to debug it more).
> After the merge, how long will we have to add some "hack" to make it work ?
>

I don't think there's any particular rush. If you want to spend a couple days to try and sort it out then go for it. We can help you as well.

> 2010/8/3 Benjamin Bentmann <[hidden email]>:
>> Jason van Zyl wrote:
>>
>>> At any rate we would like to merge these changes in and make plans to
>>> release 3.0-beta-2.
>>
>> Just in case, those changes currently live at
>> http://github.com/bentmann/maven-3/
>>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Thanks,

Jason

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

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

[Paul Benedict]

Jason, I think it would be more appropriate to get out beta-2 in its current
state. The new Guice/Aether contributions would be a significant enhancement
and are better suited for beta-3, as far as I see it. Waiting allows you to
continue getting feedback from regressions introduced in beta-2 while
working through any integration issues with your new code.

Paul

On Tue, Aug 3, 2010 at 1:21 PM, Jason van Zyl <[hidden email]> wrote:

> Hi,
>
> We have two major pieces that we, Sonatype, would like to merge into Maven
> 3.x trunk.
>
> The first are the Guice changes that we've been talking about for a while,
> and the second is the introduction of Aether which is our second attempt at
> a stand-alone repository API. The PMC is aware of Aether as Brian reported
> it in our quarterly report to the Apache Board, but other developers who are
> not on the PMC and the community in general might not know much about it.
>
> I just posted an entry giving a very high level description:
>
> http://www.sonatype.com/people/2010/08/introducing-aether/
>
> There is a resources section at the bottom of the post for those interested
> in the sources, issue tracking, wiki and mailing lists. As part of some of
> the research we are about to embark on with Daniel Le Berre, Aether will
> likely look more like p2 as time passes and as a final resting place the
> Eclipse Foundation is more likely then Apache. I know people will ask so I'm
> answering that now. Sonatype is just about to fully move Tycho over the
> Eclipse Foundation and we want to see how that goes. If that works, then
> M2Eclipse is next, and then Aether will follow.
>
> At any rate we would like to merge these changes in and make plans to
> release 3.0-beta-2.
>
> So please let us know if you have any objections.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>

[Jason van Zyl-2]

On Aug 3, 2010, at 6:18 PM, Paul Benedict wrote:

> Jason, I think it would be more appropriate to get out beta-2 in its current
> state. The new Guice/Aether contributions would be a significant enhancement
> and are better suited for beta-3, as far as I see it. Waiting allows you to
> continue getting feedback from regressions introduced in beta-2 while
> working through any integration issues with your new code.
>

Our ITs say the codebases behave in an equivalent fashion, but it's the Aether/Guice changes that will be with us for the long haul. I would rather wait to integrate those in order to suss out problems that may be a result of that integration. We found issues with Nexus on the Guice side once in production and I'm sure we're going to find similar issues with Maven. The sooner these changes make it into the hands of users the better IMO. Our testing is extensive so at this point we really do need some real world testing to find the edge cases.

> Paul
>
> On Tue, Aug 3, 2010 at 1:21 PM, Jason van Zyl <[hidden email]> wrote:
>
>> Hi,
>>
>> We have two major pieces that we, Sonatype, would like to merge into Maven
>> 3.x trunk.
>>
>> The first are the Guice changes that we've been talking about for a while,
>> and the second is the introduction of Aether which is our second attempt at
>> a stand-alone repository API. The PMC is aware of Aether as Brian reported
>> it in our quarterly report to the Apache Board, but other developers who are
>> not on the PMC and the community in general might not know much about it.
>>
>> I just posted an entry giving a very high level description:
>>
>> http://www.sonatype.com/people/2010/08/introducing-aether/
>>
>> There is a resources section at the bottom of the post for those interested
>> in the sources, issue tracking, wiki and mailing lists. As part of some of
>> the research we are about to embark on with Daniel Le Berre, Aether will
>> likely look more like p2 as time passes and as a final resting place the
>> Eclipse Foundation is more likely then Apache. I know people will ask so I'm
>> answering that now. Sonatype is just about to fully move Tycho over the
>> Eclipse Foundation and we want to see how that goes. If that works, then
>> M2Eclipse is next, and then Aether will follow.
>>
>> At any rate we would like to merge these changes in and make plans to
>> release 3.0-beta-2.
>>
>> So please let us know if you have any objections.
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in half as a bad carver might.
>>
>> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>>
>>
>>
>>

Thanks,

Jason

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

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language

[Brian Fox-2]

>
>
> Our ITs say the codebases behave in an equivalent fashion, but it's the Aether/Guice changes that will be with us for the long >haul. I would rather wait to integrate those in order to suss out problems that may be a result of that integration.

I think you meant you would rather _not_ wait.

I agree, these are the big hitters that need the most attention.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[brettporter]

On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:

> Hi,
>
> We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.

Are these reviewable distinctly? I only seem them mashed together in Benjamin's fork.

>
> The first are the Guice changes that we've been talking about for a while, and the second is the introduction of Aether which is our second attempt at a stand-alone repository API. The PMC is aware of Aether as Brian reported it in our quarterly report to the Apache Board, but other developers who are not on the PMC and the community in general might not know much about it.

Actually it wasn't. I think the only reason I know about it is because you told me directly and because I follow your twitter feed. I hope it's clear that world -> PMC -> developers is not an optimal direction for getting folks here involved.

>
> I just posted an entry giving a very high level description:
>
> http://www.sonatype.com/people/2010/08/introducing-aether/
>
> There is a resources section at the bottom of the post for those interested in the sources, issue tracking, wiki and mailing lists. As part of some of the research we are about to embark on with Daniel Le Berre, Aether will likely look more like p2 as time passes and as a final resting place the Eclipse Foundation is more likely then Apache. I know people will ask so I'm answering that now. Sonatype is just about to fully move Tycho over the Eclipse Foundation and we want to see how that goes. If that works, then M2Eclipse is next, and then Aether will follow.
>
> At any rate we would like to merge these changes in and make plans to release 3.0-beta-2.
>
> So please let us know if you have any objections.

The messages I'd seen so far seemed to indicate it would be heading back to Apache, before it was integrated into trunk. This caught me by surprise, and I'm disappointed that's not a consideration right now.

I'm torn on this. For starters, there's clearly a need for something better. One of the first tasks I created on Maven 2 (over 5 years ago now - http://jira.codehaus.org/browse/MNG-140), was to re-do maven-artifact. In the end, I never got to that task and instead built a lot on top of it before we decided to ship Maven 2, and we suffered for not revisiting it. So, bear in mind I have a fair emotional investment in the code that just got wiped away :)

On the one hand, we have a repository indexing API eventually coming in, but the repository API itself going out - that seems a bit odd. There does seem to be a lot of "Mavenisms" in the code, at least at present, that would indicate it best fits here. On the other hand, I can see the value in having a broader group participating in this effort, and in parallel simplifying Maven core to focus on more directly build-related stuff, such that it makes sense for it to be a standalone project.

My main concern is Maven chasing snapshots. For someone to address a bug or feature in Maven, they should not have to dive into a 3rd party project. I don't really know what would happen to our issue tracker as a result of this move. That problem bit me in a small way with the plexus-cipher, it has been an historical problem with Plexus itself, and I don't think "anyone can have access" really mitigates it. When 3.0 is still struggling for a final release, fragmenting issue tracking, communication and the limited documentation would seem problematic.

From a technical standpoint - I'd need more time to review, if applicable. Knowing that Benjamin does good work, I'd expect it's superior to what we have and worth moving forward with, and agree with doing that soon so that the end is in sight for 3.0. I spent a lot of time reviewing Mercury to no avail (as you similarly highlighted in your blog post), but perhaps some of the comments still apply. At a glance, my first comment is that I can't see where the line is between the Maven bits and the generic bits. For instance, if I wanted to change how the local repository works - is that pluggable from Maven, or wholly within the library?

I really only see the question of the location of the development to decide. My opinion would be to bring it here, alongside the indexer, as a subproject. Get all the effort on getting 3.0 out focused in one place, but have a clear scope to where they might go later. However, I'm not putting up any roadblocks here. The time I would have had to work on this over the last few years since trunk split off has pretty much evaporated. I'd love to get back into this particular code if it ended up somewhere I could contribute. But for now, I mostly want to encourage those who are still here to think through the implications for developing Maven.

Thanks,
Brett

--
Brett Porter
[hidden email]
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jason van Zyl-2]

On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:

>
> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>
>> Hi,
>>
>> We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.
>
> Are these reviewable distinctly? I only seem them mashed together in Benjamin's fork.
>

The Guice changes are dependency changes only. All the magic happens in the container implementation.

>
> The messages I'd seen so far seemed to indicate it would be heading back to Apache, before it was integrated into trunk. This caught me by surprise, and I'm disappointed that's not a consideration right now.
>

Ultimately it's going to be more like p2 so ultimately if it moves anywhere it will be to Eclipse.

>
> On the one hand, we have a repository indexing API eventually coming in, but the repository API itself going out - that seems a bit odd. There does seem to be a lot of "Mavenisms" in the code, at least at present, that would indicate it best fits here. On the other hand, I can see the value in having a broader group participating in this effort, and in parallel simplifying Maven core to focus on more directly build-related stuff, such that it makes sense for it to be a standalone project.
>

Many other projects are going to be integrating this code and it's likely contributions from non-Maven developers will be high. I want to collaborate in easily, I want to release once a day if necessary to accommodate integrators, I want to use best practices for fully automated releases, and I want to be able to update the website instantly. Some of these issues are in never-ending discussion mode here, and some of these things will just never happen here. I don't want to argue, and I honestly believe Aether will be healthier for it. Maven is better here because it's adopted on slower cycles and people don't pick up experimental builds. Integrators will likely be riding the bleeding edge with Aether for a while.

> My main concern is Maven chasing snapshots. For someone to address a bug or feature in Maven, they should not have to dive into a 3rd party project. I don't really know what would happen to our issue tracker as a result of this move. That problem bit me in a small way with the plexus-cipher, it has been an historical problem with Plexus itself, and I don't think "anyone can have access" really mitigates it. When 3.0 is still struggling for a final release, fragmenting issue tracking, communication and the limited documentation would seem problematic.

I believe this is a non-issue. 3rd party dependencies are a fact of life, Maven is no different then anything else in the world. Everyone has to deal with snapshot dependencies or other dependency problems in lots of projects. Again I think Aether will be healthier having more external parties involved. For working on a library it's honestly nice not having all the overhead Apache brings to the table. Apache is great for overarching products like Maven, but not so much for a sub-parts. Maybe if Apache evolved in its approach to development I might think differently in the future but that's not the experience now. We need to respond very quickly to users and integrators.

>
> From a technical standpoint - I'd need more time to review, if applicable. Knowing that Benjamin does good work, I'd expect it's superior to what we have and worth moving forward with, and agree with doing that soon so that the end is in sight for 3.0. I spent a lot of time reviewing Mercury to no avail (as you similarly highlighted in your blog post), but perhaps some of the comments still apply. At a glance, my first comment is that I can't see where the line is between the Maven bits and the generic bits. For instance, if I wanted to change how the local repository works - is that pluggable from Maven, or wholly within the library?
>

You can look at the demo to see how all the pieces fit together:

http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java

> I really only see the question of the location of the development to decide. My opinion would be to bring it here, alongside the indexer, as a subproject.

I truly believe more people will be involved in Aether if it's not here. I don't believe it's in the best interest of the development of Aether to be at Apache. If I'm wrong we can move it in the future but it honestly doesn't make any difference now from a practical stand point.

> Get all the effort on getting 3.0 out focused in one place, but have a clear scope to where they might go later. However, I'm not putting up any roadblocks here. The time I would have had to work on this over the last few years since trunk split off has pretty much evaporated. I'd love to get back into this particular code if it ended up somewhere I could contribute. But for now, I mostly want to encourage those who are still here to think through the implications for developing Maven.
>

Fair enough.

> Thanks,
> Brett
>
> --
> Brett Porter
> [hidden email]
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Thanks,

Jason

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

A language that doesn’t affect the way you think about programming is not worth knowing.
 
 -— Alan Perlis

[Ralph Goers]

I am torn on this as Brett clearly is.

I haven't contributed much code in quite a while. The reasons are simple. Maven 2 is "stable" but has serious issues that can't be fixed without breaking compatibility. Maven 3 has been under development for years with parts being ripped out and redone several times. Maybe it is me but it seems like a lot of this work has been going on within Sonatype without a whole bunch of discussion here. In any case, I was just getting the feeling that Maven 3 is stable enough to start looking at when you announce that you want to make significant changes yet again.  Not that they might not be warranted, but I am definitely not in favor of having core components of Maven hosted at a location that Maven committers don't have commit rights to.  

I find your pronouncement that it won't be here very troubling since you only have a single vote just as every other committer does.  

I'm going to have to give serious consideration as to whether I could accept this dependency without the code also residing at Apache.

Ralph


On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:

>
> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
>
>>
>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>>
>>> Hi,
>>>
>>> We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.
>>
>> Are these reviewable distinctly? I only seem them mashed together in Benjamin's fork.
>>
>
> The Guice changes are dependency changes only. All the magic happens in the container implementation.
>
>>
>> The messages I'd seen so far seemed to indicate it would be heading back to Apache, before it was integrated into trunk. This caught me by surprise, and I'm disappointed that's not a consideration right now.
>>
>
> Ultimately it's going to be more like p2 so ultimately if it moves anywhere it will be to Eclipse.
>
>>
>> On the one hand, we have a repository indexing API eventually coming in, but the repository API itself going out - that seems a bit odd. There does seem to be a lot of "Mavenisms" in the code, at least at present, that would indicate it best fits here. On the other hand, I can see the value in having a broader group participating in this effort, and in parallel simplifying Maven core to focus on more directly build-related stuff, such that it makes sense for it to be a standalone project.
>>
>
> Many other projects are going to be integrating this code and it's likely contributions from non-Maven developers will be high. I want to collaborate in easily, I want to release once a day if necessary to accommodate integrators, I want to use best practices for fully automated releases, and I want to be able to update the website instantly. Some of these issues are in never-ending discussion mode here, and some of these things will just never happen here. I don't want to argue, and I honestly believe Aether will be healthier for it. Maven is better here because it's adopted on slower cycles and people don't pick up experimental builds. Integrators will likely be riding the bleeding edge with Aether for a while.
>
>> My main concern is Maven chasing snapshots. For someone to address a bug or feature in Maven, they should not have to dive into a 3rd party project. I don't really know what would happen to our issue tracker as a result of this move. That problem bit me in a small way with the plexus-cipher, it has been an historical problem with Plexus itself, and I don't think "anyone can have access" really mitigates it. When 3.0 is still struggling for a final release, fragmenting issue tracking, communication and the limited documentation would seem problematic.
>
> I believe this is a non-issue. 3rd party dependencies are a fact of life, Maven is no different then anything else in the world. Everyone has to deal with snapshot dependencies or other dependency problems in lots of projects. Again I think Aether will be healthier having more external parties involved. For working on a library it's honestly nice not having all the overhead Apache brings to the table. Apache is great for overarching products like Maven, but not so much for a sub-parts. Maybe if Apache evolved in its approach to development I might think differently in the future but that's not the experience now. We need to respond very quickly to users and integrators.
>
>>
>> From a technical standpoint - I'd need more time to review, if applicable. Knowing that Benjamin does good work, I'd expect it's superior to what we have and worth moving forward with, and agree with doing that soon so that the end is in sight for 3.0. I spent a lot of time reviewing Mercury to no avail (as you similarly highlighted in your blog post), but perhaps some of the comments still apply. At a glance, my first comment is that I can't see where the line is between the Maven bits and the generic bits. For instance, if I wanted to change how the local repository works - is that pluggable from Maven, or wholly within the library?
>>
>
> You can look at the demo to see how all the pieces fit together:
>
> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
>
>> I really only see the question of the location of the development to decide. My opinion would be to bring it here, alongside the indexer, as a subproject.
>
> I truly believe more people will be involved in Aether if it's not here. I don't believe it's in the best interest of the development of Aether to be at Apache. If I'm wrong we can move it in the future but it honestly doesn't make any difference now from a practical stand point.
>
>> Get all the effort on getting 3.0 out focused in one place, but have a clear scope to where they might go later. However, I'm not putting up any roadblocks here. The time I would have had to work on this over the last few years since trunk split off has pretty much evaporated. I'd love to get back into this particular code if it ended up somewhere I could contribute. But for now, I mostly want to encourage those who are still here to think through the implications for developing Maven.
>>
>
> Fair enough.
>
>> Thanks,
>> Brett
>>
>> --
>> Brett Porter
>> [hidden email]
>> http://brettporter.wordpress.com/
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A language that doesn’t affect the way you think about programming is not worth knowing.
>
> -— Alan Perlis
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[stephenconnolly]

On 4 August 2010 08:06, Ralph Goers <[hidden email]> wrote:

> I am torn on this as Brett clearly is.
>
> I haven't contributed much code in quite a while. The reasons are simple.
> Maven 2 is "stable" but has serious issues that can't be fixed without
> breaking compatibility. Maven 3 has been under development for years with
> parts being ripped out and redone several times. Maybe it is me but it seems
> like a lot of this work has been going on within Sonatype without a whole
> bunch of discussion here. In any case, I was just getting the feeling that
> Maven 3 is stable enough to start looking at when you announce that you want
> to make significant changes yet again.  Not that they might not be
> warranted, but I am definitely not in favor of having core components of
> Maven hosted at a location that Maven committers don't have commit rights
> to.
>
> I find your pronouncement that it won't be here very troubling since you
> only have a single vote just as every other committer does.
>
> I'm going to have to give serious consideration as to whether I could
> accept this dependency without the code also residing at Apache.
>
>

I share concerns with respect to where the code is hosted.  I recognise that
as Apache is a meritocracy, there is a barrier for other developers getting
involved.  The Hudson model of "You want commit access, here you go" is a
tad too liberal for me, but the Apache model is too far the other way IMHO.
To some extend the codehaus model as practiced on mojo seems a good
compromise to me... but anyway aside from all that...

Maven is hosted on Apache, therefore I feel that core Maven libraries should
be hosted on Apache until they have significant adoption elsewhere... the
Maven Repository API... well that kind of says it all as far as I'm
concerned with respect to where it should live.

The Guice changes, well guice is widely adopted elsewhere, so I'm not
suggesting that Guice be relocated or forked into apache, but the Maven
specific parts of that integration.... hang about... "maven specific" says
it all again.

I have always had concerns about plexus being pretty much only adopted by
Maven as far as I can see, and essentially being a maven core component,
except it isn't

-Stephen

Ralph

>
>
> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
>
> >
> > On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
> >
> >>
> >> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
> >>
> >>> Hi,
> >>>
> >>> We have two major pieces that we, Sonatype, would like to merge into
> Maven 3.x trunk.
> >>
> >> Are these reviewable distinctly? I only seem them mashed together in
> Benjamin's fork.
> >>
> >
> > The Guice changes are dependency changes only. All the magic happens in
> the container implementation.
> >
> >>
> >> The messages I'd seen so far seemed to indicate it would be heading back
> to Apache, before it was integrated into trunk. This caught me by surprise,
> and I'm disappointed that's not a consideration right now.
> >>
> >
> > Ultimately it's going to be more like p2 so ultimately if it moves
> anywhere it will be to Eclipse.
> >
> >>
> >> On the one hand, we have a repository indexing API eventually coming in,
> but the repository API itself going out - that seems a bit odd. There does
> seem to be a lot of "Mavenisms" in the code, at least at present, that would
> indicate it best fits here. On the other hand, I can see the value in having
> a broader group participating in this effort, and in parallel simplifying
> Maven core to focus on more directly build-related stuff, such that it makes
> sense for it to be a standalone project.
> >>
> >
> > Many other projects are going to be integrating this code and it's likely
> contributions from non-Maven developers will be high. I want to collaborate
> in easily, I want to release once a day if necessary to accommodate
> integrators, I want to use best practices for fully automated releases, and
> I want to be able to update the website instantly. Some of these issues are
> in never-ending discussion mode here, and some of these things will just
> never happen here. I don't want to argue, and I honestly believe Aether will
> be healthier for it. Maven is better here because it's adopted on slower
> cycles and people don't pick up experimental builds. Integrators will likely
> be riding the bleeding edge with Aether for a while.
> >
> >> My main concern is Maven chasing snapshots. For someone to address a bug
> or feature in Maven, they should not have to dive into a 3rd party project.
> I don't really know what would happen to our issue tracker as a result of
> this move. That problem bit me in a small way with the plexus-cipher, it has
> been an historical problem with Plexus itself, and I don't think "anyone can
> have access" really mitigates it. When 3.0 is still struggling for a final
> release, fragmenting issue tracking, communication and the limited
> documentation would seem problematic.
> >
> > I believe this is a non-issue. 3rd party dependencies are a fact of life,
> Maven is no different then anything else in the world. Everyone has to deal
> with snapshot dependencies or other dependency problems in lots of projects.
> Again I think Aether will be healthier having more external parties
> involved. For working on a library it's honestly nice not having all the
> overhead Apache brings to the table. Apache is great for overarching
> products like Maven, but not so much for a sub-parts. Maybe if Apache
> evolved in its approach to development I might think differently in the
> future but that's not the experience now. We need to respond very quickly to
> users and integrators.
> >
> >>
> >> From a technical standpoint - I'd need more time to review, if
> applicable. Knowing that Benjamin does good work, I'd expect it's superior
> to what we have and worth moving forward with, and agree with doing that
> soon so that the end is in sight for 3.0. I spent a lot of time reviewing
> Mercury to no avail (as you similarly highlighted in your blog post), but
> perhaps some of the comments still apply. At a glance, my first comment is
> that I can't see where the line is between the Maven bits and the generic
> bits. For instance, if I wanted to change how the local repository works -
> is that pluggable from Maven, or wholly within the library?
> >>
> >
> > You can look at the demo to see how all the pieces fit together:
> >
> >
> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
> >
> >> I really only see the question of the location of the development to
> decide. My opinion would be to bring it here, alongside the indexer, as a
> subproject.
> >
> > I truly believe more people will be involved in Aether if it's not here.
> I don't believe it's in the best interest of the development of Aether to be
> at Apache. If I'm wrong we can move it in the future but it honestly doesn't
> make any difference now from a practical stand point.
> >
> >> Get all the effort on getting 3.0 out focused in one place, but have a
> clear scope to where they might go later. However, I'm not putting up any
> roadblocks here. The time I would have had to work on this over the last few
> years since trunk split off has pretty much evaporated. I'd love to get back
> into this particular code if it ended up somewhere I could contribute. But
> for now, I mostly want to encourage those who are still here to think
> through the implications for developing Maven.
> >>
> >
> > Fair enough.
> >
> >> Thanks,
> >> Brett
> >>
> >> --
> >> Brett Porter
> >> [hidden email]
> >> http://brettporter.wordpress.com/
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > A language that doesn’t affect the way you think about programming is not
> worth knowing.
> >
> > -— Alan Perlis
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Henri Gomez]

2010/8/4 Stephen Connolly <[hidden email]>:

> I share concerns with respect to where the code is hosted.  I recognise that
> as Apache is a meritocracy, there is a barrier for other developers getting
> involved.  The Hudson model of "You want commit access, here you go" is a
> tad too liberal for me, but the Apache model is too far the other way IMHO.
> To some extend the codehaus model as practiced on mojo seems a good
> compromise to me... but anyway aside from all that...
>
> Maven is hosted on Apache, therefore I feel that core Maven libraries should
> be hosted on Apache until they have significant adoption elsewhere... the
> Maven Repository API... well that kind of says it all as far as I'm
> concerned with respect to where it should live.
>
> The Guice changes, well guice is widely adopted elsewhere, so I'm not
> suggesting that Guice be relocated or forked into apache, but the Maven
> specific parts of that integration.... hang about... "maven specific" says
> it all again.
>
> I have always had concerns about plexus being pretty much only adopted by
> Maven as far as I can see, and essentially being a maven core component,
> except it isn't

+1

Guice allready as its own large community of users and maintainers.
It's a general 'purpose' API.

Aether is new, Maven related and need to create its own community.
Why not moving it to ASF as a Maven subproject ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[nicolas de loof-2]

>
>
> > I have always had concerns about plexus being pretty much only adopted by
> > Maven as far as I can see, and essentially being a maven core component,
> > except it isn't
>
> +1
>
> Guice allready as its own large community of users and maintainers.
> It's a general 'purpose' API.
>
> Aether is new, Maven related and need to create its own community.
> Why not moving it to ASF as a Maven subproject ?
>
>

+1 for Guice

As discussed here [1], Guice would help a lot integrating nicelly Maven3
into Hudson. It also has a larger user base and doc than Plexus, and has
been proposed for a while on this ML as a replacement. The Git branch is
also avialable for testing for a while

+0 for Aether.
It looks technicaly nice according to the code sample [2]. I just share the
concern about a major component beeing outside Maven SCM.

[1]
http://maven.40175.n5.nabble.com/Maven3-with-guice-was-Re-Maven-3-tests-td219507.html#a219507

[2]
http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java

Nicolas

[Olivier Lamy]

+1 : agree on having aether in asf too.

2010/8/4 Ralph Goers <[hidden email]>:

> I am torn on this as Brett clearly is.
>
> I haven't contributed much code in quite a while. The reasons are simple. Maven 2 is "stable" but has serious issues that can't be fixed without breaking compatibility. Maven 3 has been under development for years with parts being ripped out and redone several times. Maybe it is me but it seems like a lot of this work has been going on within Sonatype without a whole bunch of discussion here. In any case, I was just getting the feeling that Maven 3 is stable enough to start looking at when you announce that you want to make significant changes yet again.  Not that they might not be warranted, but I am definitely not in favor of having core components of Maven hosted at a location that Maven committers don't have commit rights to.
>
> I find your pronouncement that it won't be here very troubling since you only have a single vote just as every other committer does.
>
> I'm going to have to give serious consideration as to whether I could accept this dependency without the code also residing at Apache.
>
> Ralph
>
>
> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
>
>>
>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
>>
>>>
>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>>>
>>>> Hi,
>>>>
>>>> We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.
>>>
>>> Are these reviewable distinctly? I only seem them mashed together in Benjamin's fork.
>>>
>>
>> The Guice changes are dependency changes only. All the magic happens in the container implementation.
>>
>>>
>>> The messages I'd seen so far seemed to indicate it would be heading back to Apache, before it was integrated into trunk. This caught me by surprise, and I'm disappointed that's not a consideration right now.
>>>
>>
>> Ultimately it's going to be more like p2 so ultimately if it moves anywhere it will be to Eclipse.
>>
>>>
>>> On the one hand, we have a repository indexing API eventually coming in, but the repository API itself going out - that seems a bit odd. There does seem to be a lot of "Mavenisms" in the code, at least at present, that would indicate it best fits here. On the other hand, I can see the value in having a broader group participating in this effort, and in parallel simplifying Maven core to focus on more directly build-related stuff, such that it makes sense for it to be a standalone project.
>>>
>>
>> Many other projects are going to be integrating this code and it's likely contributions from non-Maven developers will be high. I want to collaborate in easily, I want to release once a day if necessary to accommodate integrators, I want to use best practices for fully automated releases, and I want to be able to update the website instantly. Some of these issues are in never-ending discussion mode here, and some of these things will just never happen here. I don't want to argue, and I honestly believe Aether will be healthier for it. Maven is better here because it's adopted on slower cycles and people don't pick up experimental builds. Integrators will likely be riding the bleeding edge with Aether for a while.
>>
>>> My main concern is Maven chasing snapshots. For someone to address a bug or feature in Maven, they should not have to dive into a 3rd party project. I don't really know what would happen to our issue tracker as a result of this move. That problem bit me in a small way with the plexus-cipher, it has been an historical problem with Plexus itself, and I don't think "anyone can have access" really mitigates it. When 3.0 is still struggling for a final release, fragmenting issue tracking, communication and the limited documentation would seem problematic.
>>
>> I believe this is a non-issue. 3rd party dependencies are a fact of life, Maven is no different then anything else in the world. Everyone has to deal with snapshot dependencies or other dependency problems in lots of projects. Again I think Aether will be healthier having more external parties involved. For working on a library it's honestly nice not having all the overhead Apache brings to the table. Apache is great for overarching products like Maven, but not so much for a sub-parts. Maybe if Apache evolved in its approach to development I might think differently in the future but that's not the experience now. We need to respond very quickly to users and integrators.
>>
>>>
>>> From a technical standpoint - I'd need more time to review, if applicable. Knowing that Benjamin does good work, I'd expect it's superior to what we have and worth moving forward with, and agree with doing that soon so that the end is in sight for 3.0. I spent a lot of time reviewing Mercury to no avail (as you similarly highlighted in your blog post), but perhaps some of the comments still apply. At a glance, my first comment is that I can't see where the line is between the Maven bits and the generic bits. For instance, if I wanted to change how the local repository works - is that pluggable from Maven, or wholly within the library?
>>>
>>
>> You can look at the demo to see how all the pieces fit together:
>>
>> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
>>
>>> I really only see the question of the location of the development to decide. My opinion would be to bring it here, alongside the indexer, as a subproject.
>>
>> I truly believe more people will be involved in Aether if it's not here. I don't believe it's in the best interest of the development of Aether to be at Apache. If I'm wrong we can move it in the future but it honestly doesn't make any difference now from a practical stand point.
>>
>>> Get all the effort on getting 3.0 out focused in one place, but have a clear scope to where they might go later. However, I'm not putting up any roadblocks here. The time I would have had to work on this over the last few years since trunk split off has pretty much evaporated. I'd love to get back into this particular code if it ended up somewhere I could contribute. But for now, I mostly want to encourage those who are still here to think through the implications for developing Maven.
>>>
>>
>> Fair enough.
>>
>>> Thanks,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> [hidden email]
>>> http://brettporter.wordpress.com/
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> A language that doesn’t affect the way you think about programming is not worth knowing.
>>
>> -— Alan Perlis
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jason van Zyl-2]

If anyone wants to -1 then you are free to do so.

I've given my reasoning for Aether not being here, I won't go on ad nauseum.

I'll leave it to the objectors to come up with a timeline for deciding. There's no rush.

On Aug 4, 2010, at 5:03 AM, Olivier Lamy wrote:

> +1 : agree on having aether in asf too.
>
> 2010/8/4 Ralph Goers <[hidden email]>:
>> I am torn on this as Brett clearly is.
>>
>> I haven't contributed much code in quite a while. The reasons are simple. Maven 2 is "stable" but has serious issues that can't be fixed without breaking compatibility. Maven 3 has been under development for years with parts being ripped out and redone several times. Maybe it is me but it seems like a lot of this work has been going on within Sonatype without a whole bunch of discussion here. In any case, I was just getting the feeling that Maven 3 is stable enough to start looking at when you announce that you want to make significant changes yet again.  Not that they might not be warranted, but I am definitely not in favor of having core components of Maven hosted at a location that Maven committers don't have commit rights to.
>>
>> I find your pronouncement that it won't be here very troubling since you only have a single vote just as every other committer does.
>>
>> I'm going to have to give serious consideration as to whether I could accept this dependency without the code also residing at Apache.
>>
>> Ralph
>>
>>
>> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
>>
>>>
>>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
>>>
>>>>
>>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.
>>>>
>>>> Are these reviewable distinctly? I only seem them mashed together in Benjamin's fork.
>>>>
>>>
>>> The Guice changes are dependency changes only. All the magic happens in the container implementation.
>>>
>>>>
>>>> The messages I'd seen so far seemed to indicate it would be heading back to Apache, before it was integrated into trunk. This caught me by surprise, and I'm disappointed that's not a consideration right now.
>>>>
>>>
>>> Ultimately it's going to be more like p2 so ultimately if it moves anywhere it will be to Eclipse.
>>>
>>>>
>>>> On the one hand, we have a repository indexing API eventually coming in, but the repository API itself going out - that seems a bit odd. There does seem to be a lot of "Mavenisms" in the code, at least at present, that would indicate it best fits here. On the other hand, I can see the value in having a broader group participating in this effort, and in parallel simplifying Maven core to focus on more directly build-related stuff, such that it makes sense for it to be a standalone project.
>>>>
>>>
>>> Many other projects are going to be integrating this code and it's likely contributions from non-Maven developers will be high. I want to collaborate in easily, I want to release once a day if necessary to accommodate integrators, I want to use best practices for fully automated releases, and I want to be able to update the website instantly. Some of these issues are in never-ending discussion mode here, and some of these things will just never happen here. I don't want to argue, and I honestly believe Aether will be healthier for it. Maven is better here because it's adopted on slower cycles and people don't pick up experimental builds. Integrators will likely be riding the bleeding edge with Aether for a while.
>>>
>>>> My main concern is Maven chasing snapshots. For someone to address a bug or feature in Maven, they should not have to dive into a 3rd party project. I don't really know what would happen to our issue tracker as a result of this move. That problem bit me in a small way with the plexus-cipher, it has been an historical problem with Plexus itself, and I don't think "anyone can have access" really mitigates it. When 3.0 is still struggling for a final release, fragmenting issue tracking, communication and the limited documentation would seem problematic.
>>>
>>> I believe this is a non-issue. 3rd party dependencies are a fact of life, Maven is no different then anything else in the world. Everyone has to deal with snapshot dependencies or other dependency problems in lots of projects. Again I think Aether will be healthier having more external parties involved. For working on a library it's honestly nice not having all the overhead Apache brings to the table. Apache is great for overarching products like Maven, but not so much for a sub-parts. Maybe if Apache evolved in its approach to development I might think differently in the future but that's not the experience now. We need to respond very quickly to users and integrators.
>>>
>>>>
>>>> From a technical standpoint - I'd need more time to review, if applicable. Knowing that Benjamin does good work, I'd expect it's superior to what we have and worth moving forward with, and agree with doing that soon so that the end is in sight for 3.0. I spent a lot of time reviewing Mercury to no avail (as you similarly highlighted in your blog post), but perhaps some of the comments still apply. At a glance, my first comment is that I can't see where the line is between the Maven bits and the generic bits. For instance, if I wanted to change how the local repository works - is that pluggable from Maven, or wholly within the library?
>>>>
>>>
>>> You can look at the demo to see how all the pieces fit together:
>>>
>>> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
>>>
>>>> I really only see the question of the location of the development to decide. My opinion would be to bring it here, alongside the indexer, as a subproject.
>>>
>>> I truly believe more people will be involved in Aether if it's not here. I don't believe it's in the best interest of the development of Aether to be at Apache. If I'm wrong we can move it in the future but it honestly doesn't make any difference now from a practical stand point.
>>>
>>>> Get all the effort on getting 3.0 out focused in one place, but have a clear scope to where they might go later. However, I'm not putting up any roadblocks here. The time I would have had to work on this over the last few years since trunk split off has pretty much evaporated. I'd love to get back into this particular code if it ended up somewhere I could contribute. But for now, I mostly want to encourage those who are still here to think through the implications for developing Maven.
>>>>
>>>
>>> Fair enough.
>>>
>>>> Thanks,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> [hidden email]
>>>> http://brettporter.wordpress.com/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> A language that doesn’t affect the way you think about programming is not worth knowing.
>>>
>>> -— Alan Perlis
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Thanks,

Jason

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

A language that doesn’t affect the way you think about programming is not worth knowing.
 
 -— Alan Perlis

[Jason van Zyl-2]

On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:

> On 4 August 2010 08:06, Ralph Goers <[hidden email]> wrote:
>
>> I am torn on this as Brett clearly is.
>>
>> I haven't contributed much code in quite a while. The reasons are simple.
>> Maven 2 is "stable" but has serious issues that can't be fixed without
>> breaking compatibility. Maven 3 has been under development for years with
>> parts being ripped out and redone several times. Maybe it is me but it seems
>> like a lot of this work has been going on within Sonatype without a whole
>> bunch of discussion here. In any case, I was just getting the feeling that
>> Maven 3 is stable enough to start looking at when you announce that you want
>> to make significant changes yet again.  Not that they might not be
>> warranted, but I am definitely not in favor of having core components of
>> Maven hosted at a location that Maven committers don't have commit rights
>> to.
>>
>> I find your pronouncement that it won't be here very troubling since you
>> only have a single vote just as every other committer does.
>>
>> I'm going to have to give serious consideration as to whether I could
>> accept this dependency without the code also residing at Apache.
>>
>>
> I share concerns with respect to where the code is hosted.  I recognise that
> as Apache is a meritocracy, there is a barrier for other developers getting
> involved.  The Hudson model of "You want commit access, here you go" is a
> tad too liberal for me, but the Apache model is too far the other way IMHO.
> To some extend the codehaus model as practiced on mojo seems a good
> compromise to me... but anyway aside from all that...
>
> Maven is hosted on Apache, therefore I feel that core Maven libraries should
> be hosted on Apache until they have significant adoption elsewhere... the
> Maven Repository API... well that kind of says it all as far as I'm
> concerned with respect to where it should live.
>
> The Guice changes, well guice is widely adopted elsewhere, so I'm not
> suggesting that Guice be relocated or forked into apache, but the Maven
> specific parts of that integration.... hang about... "maven specific" says
> it all again.

>
> I have always had concerns about plexus being pretty much only adopted by
> Maven as far as I can see, and essentially being a maven core component,
> except it isn't
>

The Guice-based container is really no different. It uses Guice as the core but we had to build the Plexus specific handling and that is a significant piece of code. It is for Plexus-based code and is being used for Maven and Nexus. Even though we will use JSR330 annotations at some point in the near future there are some Plexus-isms that will remain. It's not straight-up Guice, that simply wouldn't have worked. This code is general purpose, and I argue that so is Aether.

Of course Maven was our first target, but the two repository types of any consequence are Maven and p2. No one here has likely ever worked with a p2 repository and likely doesn't care. p2 is critical for our work, Aether will adopt/change/merge p2 concepts and having written the library we will determine its fate and it needs to be in a place where it's accessible by others is of primary importance.

During the course of development of Maven 3.x development only Kristian and Olivier have dug in. I honestly don't believe droves of people here are going to all of a sudden start making huge contributions to the effort. I want to lower the barriers for Aether's development. I believe that tools like Grade, SBT and many other integrators will adopt Aether very soon.

Having several people who haven't been even remotely involved in the project over the last year tell me what we should do with the code we wrote doesn't sit very well with me philosophically to be perfectly frank. You do the work, you earn the merit, and therefore the right to decide the fate of the code. You don't think that's justified or fair? At least initially until there is a community built around it and nothing leads me to believe given the events over the last year that the best place to grow a community for Aether is Apache.

> -Stephen
>
> Ralph
>>
>>
>> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
>>
>>>
>>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
>>>
>>>>
>>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We have two major pieces that we, Sonatype, would like to merge into
>> Maven 3.x trunk.
>>>>
>>>> Are these reviewable distinctly? I only seem them mashed together in
>> Benjamin's fork.
>>>>
>>>
>>> The Guice changes are dependency changes only. All the magic happens in
>> the container implementation.
>>>
>>>>
>>>> The messages I'd seen so far seemed to indicate it would be heading back
>> to Apache, before it was integrated into trunk. This caught me by surprise,
>> and I'm disappointed that's not a consideration right now.
>>>>
>>>
>>> Ultimately it's going to be more like p2 so ultimately if it moves
>> anywhere it will be to Eclipse.
>>>
>>>>
>>>> On the one hand, we have a repository indexing API eventually coming in,
>> but the repository API itself going out - that seems a bit odd. There does
>> seem to be a lot of "Mavenisms" in the code, at least at present, that would
>> indicate it best fits here. On the other hand, I can see the value in having
>> a broader group participating in this effort, and in parallel simplifying
>> Maven core to focus on more directly build-related stuff, such that it makes
>> sense for it to be a standalone project.
>>>>
>>>
>>> Many other projects are going to be integrating this code and it's likely
>> contributions from non-Maven developers will be high. I want to collaborate
>> in easily, I want to release once a day if necessary to accommodate
>> integrators, I want to use best practices for fully automated releases, and
>> I want to be able to update the website instantly. Some of these issues are
>> in never-ending discussion mode here, and some of these things will just
>> never happen here. I don't want to argue, and I honestly believe Aether will
>> be healthier for it. Maven is better here because it's adopted on slower
>> cycles and people don't pick up experimental builds. Integrators will likely
>> be riding the bleeding edge with Aether for a while.
>>>
>>>> My main concern is Maven chasing snapshots. For someone to address a bug
>> or feature in Maven, they should not have to dive into a 3rd party project.
>> I don't really know what would happen to our issue tracker as a result of
>> this move. That problem bit me in a small way with the plexus-cipher, it has
>> been an historical problem with Plexus itself, and I don't think "anyone can
>> have access" really mitigates it. When 3.0 is still struggling for a final
>> release, fragmenting issue tracking, communication and the limited
>> documentation would seem problematic.
>>>
>>> I believe this is a non-issue. 3rd party dependencies are a fact of life,
>> Maven is no different then anything else in the world. Everyone has to deal
>> with snapshot dependencies or other dependency problems in lots of projects.
>> Again I think Aether will be healthier having more external parties
>> involved. For working on a library it's honestly nice not having all the
>> overhead Apache brings to the table. Apache is great for overarching
>> products like Maven, but not so much for a sub-parts. Maybe if Apache
>> evolved in its approach to development I might think differently in the
>> future but that's not the experience now. We need to respond very quickly to
>> users and integrators.
>>>
>>>>
>>>> From a technical standpoint - I'd need more time to review, if
>> applicable. Knowing that Benjamin does good work, I'd expect it's superior
>> to what we have and worth moving forward with, and agree with doing that
>> soon so that the end is in sight for 3.0. I spent a lot of time reviewing
>> Mercury to no avail (as you similarly highlighted in your blog post), but
>> perhaps some of the comments still apply. At a glance, my first comment is
>> that I can't see where the line is between the Maven bits and the generic
>> bits. For instance, if I wanted to change how the local repository works -
>> is that pluggable from Maven, or wholly within the library?
>>>>
>>>
>>> You can look at the demo to see how all the pieces fit together:
>>>
>>>
>> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
>>>
>>>> I really only see the question of the location of the development to
>> decide. My opinion would be to bring it here, alongside the indexer, as a
>> subproject.
>>>
>>> I truly believe more people will be involved in Aether if it's not here.
>> I don't believe it's in the best interest of the development of Aether to be
>> at Apache. If I'm wrong we can move it in the future but it honestly doesn't
>> make any difference now from a practical stand point.
>>>
>>>> Get all the effort on getting 3.0 out focused in one place, but have a
>> clear scope to where they might go later. However, I'm not putting up any
>> roadblocks here. The time I would have had to work on this over the last few
>> years since trunk split off has pretty much evaporated. I'd love to get back
>> into this particular code if it ended up somewhere I could contribute. But
>> for now, I mostly want to encourage those who are still here to think
>> through the implications for developing Maven.
>>>>
>>>
>>> Fair enough.
>>>
>>>> Thanks,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> [hidden email]
>>>> http://brettporter.wordpress.com/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> A language that doesn’t affect the way you think about programming is not
>> worth knowing.
>>>
>>> -— Alan Perlis
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

Thanks,

Jason

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

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

[Jason van Zyl-2]

We can also all pop into IRC if you want a more productive, real-time discussion. Also happy to host a call. Might as well get everything aired out sooner rather then later.

On Aug 4, 2010, at 7:35 AM, Jason van Zyl wrote:

>
> On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:
>
>> On 4 August 2010 08:06, Ralph Goers <[hidden email]> wrote:
>>
>>> I am torn on this as Brett clearly is.
>>>
>>> I haven't contributed much code in quite a while. The reasons are simple.
>>> Maven 2 is "stable" but has serious issues that can't be fixed without
>>> breaking compatibility. Maven 3 has been under development for years with
>>> parts being ripped out and redone several times. Maybe it is me but it seems
>>> like a lot of this work has been going on within Sonatype without a whole
>>> bunch of discussion here. In any case, I was just getting the feeling that
>>> Maven 3 is stable enough to start looking at when you announce that you want
>>> to make significant changes yet again.  Not that they might not be
>>> warranted, but I am definitely not in favor of having core components of
>>> Maven hosted at a location that Maven committers don't have commit rights
>>> to.
>>>
>>> I find your pronouncement that it won't be here very troubling since you
>>> only have a single vote just as every other committer does.
>>>
>>> I'm going to have to give serious consideration as to whether I could
>>> accept this dependency without the code also residing at Apache.
>>>
>>>
>> I share concerns with respect to where the code is hosted.  I recognise that
>> as Apache is a meritocracy, there is a barrier for other developers getting
>> involved.  The Hudson model of "You want commit access, here you go" is a
>> tad too liberal for me, but the Apache model is too far the other way IMHO.
>> To some extend the codehaus model as practiced on mojo seems a good
>> compromise to me... but anyway aside from all that...
>>
>> Maven is hosted on Apache, therefore I feel that core Maven libraries should
>> be hosted on Apache until they have significant adoption elsewhere... the
>> Maven Repository API... well that kind of says it all as far as I'm
>> concerned with respect to where it should live.
>>
>> The Guice changes, well guice is widely adopted elsewhere, so I'm not
>> suggesting that Guice be relocated or forked into apache, but the Maven
>> specific parts of that integration.... hang about... "maven specific" says
>> it all again.
>
>>
>> I have always had concerns about plexus being pretty much only adopted by
>> Maven as far as I can see, and essentially being a maven core component,
>> except it isn't
>>
>
> The Guice-based container is really no different. It uses Guice as the core but we had to build the Plexus specific handling and that is a significant piece of code. It is for Plexus-based code and is being used for Maven and Nexus. Even though we will use JSR330 annotations at some point in the near future there are some Plexus-isms that will remain. It's not straight-up Guice, that simply wouldn't have worked. This code is general purpose, and I argue that so is Aether.
>
> Of course Maven was our first target, but the two repository types of any consequence are Maven and p2. No one here has likely ever worked with a p2 repository and likely doesn't care. p2 is critical for our work, Aether will adopt/change/merge p2 concepts and having written the library we will determine its fate and it needs to be in a place where it's accessible by others is of primary importance.
>
> During the course of development of Maven 3.x development only Kristian and Olivier have dug in. I honestly don't believe droves of people here are going to all of a sudden start making huge contributions to the effort. I want to lower the barriers for Aether's development. I believe that tools like Grade, SBT and many other integrators will adopt Aether very soon.
>
> Having several people who haven't been even remotely involved in the project over the last year tell me what we should do with the code we wrote doesn't sit very well with me philosophically to be perfectly frank. You do the work, you earn the merit, and therefore the right to decide the fate of the code. You don't think that's justified or fair? At least initially until there is a community built around it and nothing leads me to believe given the events over the last year that the best place to grow a community for Aether is Apache.
>
>> -Stephen
>>
>> Ralph
>>>
>>>
>>> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
>>>
>>>>
>>>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
>>>>
>>>>>
>>>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We have two major pieces that we, Sonatype, would like to merge into
>>> Maven 3.x trunk.
>>>>>
>>>>> Are these reviewable distinctly? I only seem them mashed together in
>>> Benjamin's fork.
>>>>>
>>>>
>>>> The Guice changes are dependency changes only. All the magic happens in
>>> the container implementation.
>>>>
>>>>>
>>>>> The messages I'd seen so far seemed to indicate it would be heading back
>>> to Apache, before it was integrated into trunk. This caught me by surprise,
>>> and I'm disappointed that's not a consideration right now.
>>>>>
>>>>
>>>> Ultimately it's going to be more like p2 so ultimately if it moves
>>> anywhere it will be to Eclipse.
>>>>
>>>>>
>>>>> On the one hand, we have a repository indexing API eventually coming in,
>>> but the repository API itself going out - that seems a bit odd. There does
>>> seem to be a lot of "Mavenisms" in the code, at least at present, that would
>>> indicate it best fits here. On the other hand, I can see the value in having
>>> a broader group participating in this effort, and in parallel simplifying
>>> Maven core to focus on more directly build-related stuff, such that it makes
>>> sense for it to be a standalone project.
>>>>>
>>>>
>>>> Many other projects are going to be integrating this code and it's likely
>>> contributions from non-Maven developers will be high. I want to collaborate
>>> in easily, I want to release once a day if necessary to accommodate
>>> integrators, I want to use best practices for fully automated releases, and
>>> I want to be able to update the website instantly. Some of these issues are
>>> in never-ending discussion mode here, and some of these things will just
>>> never happen here. I don't want to argue, and I honestly believe Aether will
>>> be healthier for it. Maven is better here because it's adopted on slower
>>> cycles and people don't pick up experimental builds. Integrators will likely
>>> be riding the bleeding edge with Aether for a while.
>>>>
>>>>> My main concern is Maven chasing snapshots. For someone to address a bug
>>> or feature in Maven, they should not have to dive into a 3rd party project.
>>> I don't really know what would happen to our issue tracker as a result of
>>> this move. That problem bit me in a small way with the plexus-cipher, it has
>>> been an historical problem with Plexus itself, and I don't think "anyone can
>>> have access" really mitigates it. When 3.0 is still struggling for a final
>>> release, fragmenting issue tracking, communication and the limited
>>> documentation would seem problematic.
>>>>
>>>> I believe this is a non-issue. 3rd party dependencies are a fact of life,
>>> Maven is no different then anything else in the world. Everyone has to deal
>>> with snapshot dependencies or other dependency problems in lots of projects.
>>> Again I think Aether will be healthier having more external parties
>>> involved. For working on a library it's honestly nice not having all the
>>> overhead Apache brings to the table. Apache is great for overarching
>>> products like Maven, but not so much for a sub-parts. Maybe if Apache
>>> evolved in its approach to development I might think differently in the
>>> future but that's not the experience now. We need to respond very quickly to
>>> users and integrators.
>>>>
>>>>>
>>>>> From a technical standpoint - I'd need more time to review, if
>>> applicable. Knowing that Benjamin does good work, I'd expect it's superior
>>> to what we have and worth moving forward with, and agree with doing that
>>> soon so that the end is in sight for 3.0. I spent a lot of time reviewing
>>> Mercury to no avail (as you similarly highlighted in your blog post), but
>>> perhaps some of the comments still apply. At a glance, my first comment is
>>> that I can't see where the line is between the Maven bits and the generic
>>> bits. For instance, if I wanted to change how the local repository works -
>>> is that pluggable from Maven, or wholly within the library?
>>>>>
>>>>
>>>> You can look at the demo to see how all the pieces fit together:
>>>>
>>>>
>>> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
>>>>
>>>>> I really only see the question of the location of the development to
>>> decide. My opinion would be to bring it here, alongside the indexer, as a
>>> subproject.
>>>>
>>>> I truly believe more people will be involved in Aether if it's not here.
>>> I don't believe it's in the best interest of the development of Aether to be
>>> at Apache. If I'm wrong we can move it in the future but it honestly doesn't
>>> make any difference now from a practical stand point.
>>>>
>>>>> Get all the effort on getting 3.0 out focused in one place, but have a
>>> clear scope to where they might go later. However, I'm not putting up any
>>> roadblocks here. The time I would have had to work on this over the last few
>>> years since trunk split off has pretty much evaporated. I'd love to get back
>>> into this particular code if it ended up somewhere I could contribute. But
>>> for now, I mostly want to encourage those who are still here to think
>>> through the implications for developing Maven.
>>>>>
>>>>
>>>> Fair enough.
>>>>
>>>>> Thanks,
>>>>> Brett
>>>>>
>>>>> --
>>>>> Brett Porter
>>>>> [hidden email]
>>>>> http://brettporter.wordpress.com/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> A language that doesn’t affect the way you think about programming is not
>>> worth knowing.
>>>>
>>>> -— Alan Perlis
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>

Thanks,

Jason

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

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

[stephenconnolly]

I was saying that I see Guice as being different than Aether... the
plexus-guice shim though I see as being separate from Guice.

I also said that I recognise that the bar for egtting committer access at
apache is probably a little too high for something like Aether.

And, unlike others, I was only saying that I am uncomfortable.  If work
committments had not been as pressing this last 8 months I would have been
more heavily involved in M3, but we can all sometimes make the mistake of
believing lies about effort now saving the site you work at ;-)

-Stephen

On 4 August 2010 12:35, Jason van Zyl <[hidden email]> wrote:

>
> On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:
>
> > On 4 August 2010 08:06, Ralph Goers <[hidden email]> wrote:
> >
> >> I am torn on this as Brett clearly is.
> >>
> >> I haven't contributed much code in quite a while. The reasons are
> simple.
> >> Maven 2 is "stable" but has serious issues that can't be fixed without
> >> breaking compatibility. Maven 3 has been under development for years
> with
> >> parts being ripped out and redone several times. Maybe it is me but it
> seems
> >> like a lot of this work has been going on within Sonatype without a
> whole
> >> bunch of discussion here. In any case, I was just getting the feeling
> that
> >> Maven 3 is stable enough to start looking at when you announce that you
> want
> >> to make significant changes yet again.  Not that they might not be
> >> warranted, but I am definitely not in favor of having core components of
> >> Maven hosted at a location that Maven committers don't have commit
> rights
> >> to.
> >>
> >> I find your pronouncement that it won't be here very troubling since you
> >> only have a single vote just as every other committer does.
> >>
> >> I'm going to have to give serious consideration as to whether I could
> >> accept this dependency without the code also residing at Apache.
> >>
> >>
> > I share concerns with respect to where the code is hosted.  I recognise
> that
> > as Apache is a meritocracy, there is a barrier for other developers
> getting
> > involved.  The Hudson model of "You want commit access, here you go" is a
> > tad too liberal for me, but the Apache model is too far the other way
> IMHO.
> > To some extend the codehaus model as practiced on mojo seems a good
> > compromise to me... but anyway aside from all that...
> >
> > Maven is hosted on Apache, therefore I feel that core Maven libraries
> should
> > be hosted on Apache until they have significant adoption elsewhere... the
> > Maven Repository API... well that kind of says it all as far as I'm
> > concerned with respect to where it should live.
> >
> > The Guice changes, well guice is widely adopted elsewhere, so I'm not
> > suggesting that Guice be relocated or forked into apache, but the Maven
> > specific parts of that integration.... hang about... "maven specific"
> says
> > it all again.
>
> >
> > I have always had concerns about plexus being pretty much only adopted by
> > Maven as far as I can see, and essentially being a maven core component,
> > except it isn't
> >
>
> The Guice-based container is really no different. It uses Guice as the core
> but we had to build the Plexus specific handling and that is a significant
> piece of code. It is for Plexus-based code and is being used for Maven and
> Nexus. Even though we will use JSR330 annotations at some point in the near
> future there are some Plexus-isms that will remain. It's not straight-up
> Guice, that simply wouldn't have worked. This code is general purpose, and I
> argue that so is Aether.
>
> Of course Maven was our first target, but the two repository types of any
> consequence are Maven and p2. No one here has likely ever worked with a p2
> repository and likely doesn't care. p2 is critical for our work, Aether will
> adopt/change/merge p2 concepts and having written the library we will
> determine its fate and it needs to be in a place where it's accessible by
> others is of primary importance.
>
> During the course of development of Maven 3.x development only Kristian and
> Olivier have dug in. I honestly don't believe droves of people here are
> going to all of a sudden start making huge contributions to the effort. I
> want to lower the barriers for Aether's development. I believe that tools
> like Grade, SBT and many other integrators will adopt Aether very soon.
>
> Having several people who haven't been even remotely involved in the
> project over the last year tell me what we should do with the code we wrote
> doesn't sit very well with me philosophically to be perfectly frank. You do
> the work, you earn the merit, and therefore the right to decide the fate of
> the code. You don't think that's justified or fair? At least initially until
> there is a community built around it and nothing leads me to believe given
> the events over the last year that the best place to grow a community for
> Aether is Apache.
>
> > -Stephen
> >
> > Ralph
> >>
> >>
> >> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
> >>
> >>>
> >>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
> >>>
> >>>>
> >>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> We have two major pieces that we, Sonatype, would like to merge into
> >> Maven 3.x trunk.
> >>>>
> >>>> Are these reviewable distinctly? I only seem them mashed together in
> >> Benjamin's fork.
> >>>>
> >>>
> >>> The Guice changes are dependency changes only. All the magic happens in
> >> the container implementation.
> >>>
> >>>>
> >>>> The messages I'd seen so far seemed to indicate it would be heading
> back
> >> to Apache, before it was integrated into trunk. This caught me by
> surprise,
> >> and I'm disappointed that's not a consideration right now.
> >>>>
> >>>
> >>> Ultimately it's going to be more like p2 so ultimately if it moves
> >> anywhere it will be to Eclipse.
> >>>
> >>>>
> >>>> On the one hand, we have a repository indexing API eventually coming
> in,
> >> but the repository API itself going out - that seems a bit odd. There
> does
> >> seem to be a lot of "Mavenisms" in the code, at least at present, that
> would
> >> indicate it best fits here. On the other hand, I can see the value in
> having
> >> a broader group participating in this effort, and in parallel
> simplifying
> >> Maven core to focus on more directly build-related stuff, such that it
> makes
> >> sense for it to be a standalone project.
> >>>>
> >>>
> >>> Many other projects are going to be integrating this code and it's
> likely
> >> contributions from non-Maven developers will be high. I want to
> collaborate
> >> in easily, I want to release once a day if necessary to accommodate
> >> integrators, I want to use best practices for fully automated releases,
> and
> >> I want to be able to update the website instantly. Some of these issues
> are
> >> in never-ending discussion mode here, and some of these things will just
> >> never happen here. I don't want to argue, and I honestly believe Aether
> will
> >> be healthier for it. Maven is better here because it's adopted on slower
> >> cycles and people don't pick up experimental builds. Integrators will
> likely
> >> be riding the bleeding edge with Aether for a while.
> >>>
> >>>> My main concern is Maven chasing snapshots. For someone to address a
> bug
> >> or feature in Maven, they should not have to dive into a 3rd party
> project.
> >> I don't really know what would happen to our issue tracker as a result
> of
> >> this move. That problem bit me in a small way with the plexus-cipher, it
> has
> >> been an historical problem with Plexus itself, and I don't think "anyone
> can
> >> have access" really mitigates it. When 3.0 is still struggling for a
> final
> >> release, fragmenting issue tracking, communication and the limited
> >> documentation would seem problematic.
> >>>
> >>> I believe this is a non-issue. 3rd party dependencies are a fact of
> life,
> >> Maven is no different then anything else in the world. Everyone has to
> deal
> >> with snapshot dependencies or other dependency problems in lots of
> projects.
> >> Again I think Aether will be healthier having more external parties
> >> involved. For working on a library it's honestly nice not having all the
> >> overhead Apache brings to the table. Apache is great for overarching
> >> products like Maven, but not so much for a sub-parts. Maybe if Apache
> >> evolved in its approach to development I might think differently in the
> >> future but that's not the experience now. We need to respond very
> quickly to
> >> users and integrators.
> >>>
> >>>>
> >>>> From a technical standpoint - I'd need more time to review, if
> >> applicable. Knowing that Benjamin does good work, I'd expect it's
> superior
> >> to what we have and worth moving forward with, and agree with doing that
> >> soon so that the end is in sight for 3.0. I spent a lot of time
> reviewing
> >> Mercury to no avail (as you similarly highlighted in your blog post),
> but
> >> perhaps some of the comments still apply. At a glance, my first comment
> is
> >> that I can't see where the line is between the Maven bits and the
> generic
> >> bits. For instance, if I wanted to change how the local repository works
> -
> >> is that pluggable from Maven, or wholly within the library?
> >>>>
> >>>
> >>> You can look at the demo to see how all the pieces fit together:
> >>>
> >>>
> >>
> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
> >>>
> >>>> I really only see the question of the location of the development to
> >> decide. My opinion would be to bring it here, alongside the indexer, as
> a
> >> subproject.
> >>>
> >>> I truly believe more people will be involved in Aether if it's not
> here.
> >> I don't believe it's in the best interest of the development of Aether
> to be
> >> at Apache. If I'm wrong we can move it in the future but it honestly
> doesn't
> >> make any difference now from a practical stand point.
> >>>
> >>>> Get all the effort on getting 3.0 out focused in one place, but have a
> >> clear scope to where they might go later. However, I'm not putting up
> any
> >> roadblocks here. The time I would have had to work on this over the last
> few
> >> years since trunk split off has pretty much evaporated. I'd love to get
> back
> >> into this particular code if it ended up somewhere I could contribute.
> But
> >> for now, I mostly want to encourage those who are still here to think
> >> through the implications for developing Maven.
> >>>>
> >>>
> >>> Fair enough.
> >>>
> >>>> Thanks,
> >>>> Brett
> >>>>
> >>>> --
> >>>> Brett Porter
> >>>> [hidden email]
> >>>> http://brettporter.wordpress.com/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder,  Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> ---------------------------------------------------------
> >>>
> >>> A language that doesn’t affect the way you think about programming is
> not
> >> worth knowing.
> >>>
> >>> -— Alan Perlis
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>

[stephenconnolly]

My experience is that a high barrier to committ access actually makes life
harder for committers.  I have commit access to Maven but not to plexus....
sometimes when working on Maven Plugins I've found I need to do something in
plexus to resolve an issue, and I've hit the wall because I have to stop to
get committ access or start submitting patches and fight for sponsors...
next thing you know my momentum is gone, and I move on to something else.

If Aether has commit access for all Maven committers automatically, (and I'm
not saying it doesn't) then a large part of my concerns can be removed... I
recognise the p2 stuff as being a separate concern from the m2 repo
stuff.... and if that's the case then you need to sell Aether as such and
not try to sell it as a Maven Repo API.

-Stephen

On 4 August 2010 13:31, Stephen Connolly <[hidden email]>wrote:

> I was saying that I see Guice as being different than Aether... the
> plexus-guice shim though I see as being separate from Guice.
>
> I also said that I recognise that the bar for egtting committer access at
> apache is probably a little too high for something like Aether.
>
> And, unlike others, I was only saying that I am uncomfortable.  If work
> committments had not been as pressing this last 8 months I would have been
> more heavily involved in M3, but we can all sometimes make the mistake of
> believing lies about effort now saving the site you work at ;-)
>
> -Stephen
>
>
> On 4 August 2010 12:35, Jason van Zyl <[hidden email]> wrote:
>
>>
>> On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:
>>
>> > On 4 August 2010 08:06, Ralph Goers <[hidden email]> wrote:
>> >
>> >> I am torn on this as Brett clearly is.
>> >>
>> >> I haven't contributed much code in quite a while. The reasons are
>> simple.
>> >> Maven 2 is "stable" but has serious issues that can't be fixed without
>> >> breaking compatibility. Maven 3 has been under development for years
>> with
>> >> parts being ripped out and redone several times. Maybe it is me but it
>> seems
>> >> like a lot of this work has been going on within Sonatype without a
>> whole
>> >> bunch of discussion here. In any case, I was just getting the feeling
>> that
>> >> Maven 3 is stable enough to start looking at when you announce that you
>> want
>> >> to make significant changes yet again.  Not that they might not be
>> >> warranted, but I am definitely not in favor of having core components
>> of
>> >> Maven hosted at a location that Maven committers don't have commit
>> rights
>> >> to.
>> >>
>> >> I find your pronouncement that it won't be here very troubling since
>> you
>> >> only have a single vote just as every other committer does.
>> >>
>> >> I'm going to have to give serious consideration as to whether I could
>> >> accept this dependency without the code also residing at Apache.
>> >>
>> >>
>> > I share concerns with respect to where the code is hosted.  I recognise
>> that
>> > as Apache is a meritocracy, there is a barrier for other developers
>> getting
>> > involved.  The Hudson model of "You want commit access, here you go" is
>> a
>> > tad too liberal for me, but the Apache model is too far the other way
>> IMHO.
>> > To some extend the codehaus model as practiced on mojo seems a good
>> > compromise to me... but anyway aside from all that...
>> >
>> > Maven is hosted on Apache, therefore I feel that core Maven libraries
>> should
>> > be hosted on Apache until they have significant adoption elsewhere...
>> the
>> > Maven Repository API... well that kind of says it all as far as I'm
>> > concerned with respect to where it should live.
>> >
>> > The Guice changes, well guice is widely adopted elsewhere, so I'm not
>> > suggesting that Guice be relocated or forked into apache, but the Maven
>> > specific parts of that integration.... hang about... "maven specific"
>> says
>> > it all again.
>>
>> >
>> > I have always had concerns about plexus being pretty much only adopted
>> by
>> > Maven as far as I can see, and essentially being a maven core component,
>> > except it isn't
>> >
>>
>> The Guice-based container is really no different. It uses Guice as the
>> core but we had to build the Plexus specific handling and that is a
>> significant piece of code. It is for Plexus-based code and is being used for
>> Maven and Nexus. Even though we will use JSR330 annotations at some point in
>> the near future there are some Plexus-isms that will remain. It's not
>> straight-up Guice, that simply wouldn't have worked. This code is general
>> purpose, and I argue that so is Aether.
>>
>> Of course Maven was our first target, but the two repository types of any
>> consequence are Maven and p2. No one here has likely ever worked with a p2
>> repository and likely doesn't care. p2 is critical for our work, Aether will
>> adopt/change/merge p2 concepts and having written the library we will
>> determine its fate and it needs to be in a place where it's accessible by
>> others is of primary importance.
>>
>> During the course of development of Maven 3.x development only Kristian
>> and Olivier have dug in. I honestly don't believe droves of people here are
>> going to all of a sudden start making huge contributions to the effort. I
>> want to lower the barriers for Aether's development. I believe that tools
>> like Grade, SBT and many other integrators will adopt Aether very soon.
>>
>> Having several people who haven't been even remotely involved in the
>> project over the last year tell me what we should do with the code we wrote
>> doesn't sit very well with me philosophically to be perfectly frank. You do
>> the work, you earn the merit, and therefore the right to decide the fate of
>> the code. You don't think that's justified or fair? At least initially until
>> there is a community built around it and nothing leads me to believe given
>> the events over the last year that the best place to grow a community for
>> Aether is Apache.
>>
>> > -Stephen
>> >
>> > Ralph
>> >>
>> >>
>> >> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
>> >>
>> >>>
>> >>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
>> >>>
>> >>>>
>> >>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
>> >>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> We have two major pieces that we, Sonatype, would like to merge into
>> >> Maven 3.x trunk.
>> >>>>
>> >>>> Are these reviewable distinctly? I only seem them mashed together in
>> >> Benjamin's fork.
>> >>>>
>> >>>
>> >>> The Guice changes are dependency changes only. All the magic happens
>> in
>> >> the container implementation.
>> >>>
>> >>>>
>> >>>> The messages I'd seen so far seemed to indicate it would be heading
>> back
>> >> to Apache, before it was integrated into trunk. This caught me by
>> surprise,
>> >> and I'm disappointed that's not a consideration right now.
>> >>>>
>> >>>
>> >>> Ultimately it's going to be more like p2 so ultimately if it moves
>> >> anywhere it will be to Eclipse.
>> >>>
>> >>>>
>> >>>> On the one hand, we have a repository indexing API eventually coming
>> in,
>> >> but the repository API itself going out - that seems a bit odd. There
>> does
>> >> seem to be a lot of "Mavenisms" in the code, at least at present, that
>> would
>> >> indicate it best fits here. On the other hand, I can see the value in
>> having
>> >> a broader group participating in this effort, and in parallel
>> simplifying
>> >> Maven core to focus on more directly build-related stuff, such that it
>> makes
>> >> sense for it to be a standalone project.
>> >>>>
>> >>>
>> >>> Many other projects are going to be integrating this code and it's
>> likely
>> >> contributions from non-Maven developers will be high. I want to
>> collaborate
>> >> in easily, I want to release once a day if necessary to accommodate
>> >> integrators, I want to use best practices for fully automated releases,
>> and
>> >> I want to be able to update the website instantly. Some of these issues
>> are
>> >> in never-ending discussion mode here, and some of these things will
>> just
>> >> never happen here. I don't want to argue, and I honestly believe Aether
>> will
>> >> be healthier for it. Maven is better here because it's adopted on
>> slower
>> >> cycles and people don't pick up experimental builds. Integrators will
>> likely
>> >> be riding the bleeding edge with Aether for a while.
>> >>>
>> >>>> My main concern is Maven chasing snapshots. For someone to address a
>> bug
>> >> or feature in Maven, they should not have to dive into a 3rd party
>> project.
>> >> I don't really know what would happen to our issue tracker as a result
>> of
>> >> this move. That problem bit me in a small way with the plexus-cipher,
>> it has
>> >> been an historical problem with Plexus itself, and I don't think
>> "anyone can
>> >> have access" really mitigates it. When 3.0 is still struggling for a
>> final
>> >> release, fragmenting issue tracking, communication and the limited
>> >> documentation would seem problematic.
>> >>>
>> >>> I believe this is a non-issue. 3rd party dependencies are a fact of
>> life,
>> >> Maven is no different then anything else in the world. Everyone has to
>> deal
>> >> with snapshot dependencies or other dependency problems in lots of
>> projects.
>> >> Again I think Aether will be healthier having more external parties
>> >> involved. For working on a library it's honestly nice not having all
>> the
>> >> overhead Apache brings to the table. Apache is great for overarching
>> >> products like Maven, but not so much for a sub-parts. Maybe if Apache
>> >> evolved in its approach to development I might think differently in the
>> >> future but that's not the experience now. We need to respond very
>> quickly to
>> >> users and integrators.
>> >>>
>> >>>>
>> >>>> From a technical standpoint - I'd need more time to review, if
>> >> applicable. Knowing that Benjamin does good work, I'd expect it's
>> superior
>> >> to what we have and worth moving forward with, and agree with doing
>> that
>> >> soon so that the end is in sight for 3.0. I spent a lot of time
>> reviewing
>> >> Mercury to no avail (as you similarly highlighted in your blog post),
>> but
>> >> perhaps some of the comments still apply. At a glance, my first comment
>> is
>> >> that I can't see where the line is between the Maven bits and the
>> generic
>> >> bits. For instance, if I wanted to change how the local repository
>> works -
>> >> is that pluggable from Maven, or wholly within the library?
>> >>>>
>> >>>
>> >>> You can look at the demo to see how all the pieces fit together:
>> >>>
>> >>>
>> >>
>> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
>> >>>
>> >>>> I really only see the question of the location of the development to
>> >> decide. My opinion would be to bring it here, alongside the indexer, as
>> a
>> >> subproject.
>> >>>
>> >>> I truly believe more people will be involved in Aether if it's not
>> here.
>> >> I don't believe it's in the best interest of the development of Aether
>> to be
>> >> at Apache. If I'm wrong we can move it in the future but it honestly
>> doesn't
>> >> make any difference now from a practical stand point.
>> >>>
>> >>>> Get all the effort on getting 3.0 out focused in one place, but have
>> a
>> >> clear scope to where they might go later. However, I'm not putting up
>> any
>> >> roadblocks here. The time I would have had to work on this over the
>> last few
>> >> years since trunk split off has pretty much evaporated. I'd love to get
>> back
>> >> into this particular code if it ended up somewhere I could contribute.
>> But
>> >> for now, I mostly want to encourage those who are still here to think
>> >> through the implications for developing Maven.
>> >>>>
>> >>>
>> >>> Fair enough.
>> >>>
>> >>>> Thanks,
>> >>>> Brett
>> >>>>
>> >>>> --
>> >>>> Brett Porter
>> >>>> [hidden email]
>> >>>> http://brettporter.wordpress.com/
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [hidden email]
>> >>>> For additional commands, e-mail: [hidden email]
>> >>>>
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Jason
>> >>>
>> >>> ----------------------------------------------------------
>> >>> Jason van Zyl
>> >>> Founder,  Apache Maven
>> >>> http://twitter.com/jvanzyl
>> >>> ---------------------------------------------------------
>> >>>
>> >>> A language that doesn’t affect the way you think about programming is
>> not
>> >> worth knowing.
>> >>>
>> >>> -— Alan Perlis
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in half as a bad carver might.
>>
>>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>>
>>
>>
>>
>

[Paul Benedict]

Although I am not a committer at Maven, I also share the sentiment that
Maven 3's external development hinders community development at Apache. It's
difficult to know where things are going -- and usually I feel the direction
is wholly controlled by Sonatype. I have no problems with commercial
endeavors and making money off your own sweat (Jason, congrats on building
that company!), but I say the the divided allegiances is a turn off. If I
wanted to contribute to Maven's core, I want to do so without worrying what
other designs are brewing in external communities/organizations.

Paul

On Wed, Aug 4, 2010 at 7:31 AM, Stephen Connolly <
[hidden email]> wrote:

> I was saying that I see Guice as being different than Aether... the
> plexus-guice shim though I see as being separate from Guice.
>
> I also said that I recognise that the bar for egtting committer access at
> apache is probably a little too high for something like Aether.
>
> And, unlike others, I was only saying that I am uncomfortable.  If work
> committments had not been as pressing this last 8 months I would have been
> more heavily involved in M3, but we can all sometimes make the mistake of
> believing lies about effort now saving the site you work at ;-)
>
> -Stephen
>
> On 4 August 2010 12:35, Jason van Zyl <[hidden email]> wrote:
>
> >
> > On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:
> >
> > > On 4 August 2010 08:06, Ralph Goers <[hidden email]>
> wrote:
> > >
> > >> I am torn on this as Brett clearly is.
> > >>
> > >> I haven't contributed much code in quite a while. The reasons are
> > simple.
> > >> Maven 2 is "stable" but has serious issues that can't be fixed without
> > >> breaking compatibility. Maven 3 has been under development for years
> > with
> > >> parts being ripped out and redone several times. Maybe it is me but it
> > seems
> > >> like a lot of this work has been going on within Sonatype without a
> > whole
> > >> bunch of discussion here. In any case, I was just getting the feeling
> > that
> > >> Maven 3 is stable enough to start looking at when you announce that
> you
> > want
> > >> to make significant changes yet again.  Not that they might not be
> > >> warranted, but I am definitely not in favor of having core components
> of
> > >> Maven hosted at a location that Maven committers don't have commit
> > rights
> > >> to.
> > >>
> > >> I find your pronouncement that it won't be here very troubling since
> you
> > >> only have a single vote just as every other committer does.
> > >>
> > >> I'm going to have to give serious consideration as to whether I could
> > >> accept this dependency without the code also residing at Apache.
> > >>
> > >>
> > > I share concerns with respect to where the code is hosted.  I recognise
> > that
> > > as Apache is a meritocracy, there is a barrier for other developers
> > getting
> > > involved.  The Hudson model of "You want commit access, here you go" is
> a
> > > tad too liberal for me, but the Apache model is too far the other way
> > IMHO.
> > > To some extend the codehaus model as practiced on mojo seems a good
> > > compromise to me... but anyway aside from all that...
> > >
> > > Maven is hosted on Apache, therefore I feel that core Maven libraries
> > should
> > > be hosted on Apache until they have significant adoption elsewhere...
> the
> > > Maven Repository API... well that kind of says it all as far as I'm
> > > concerned with respect to where it should live.
> > >
> > > The Guice changes, well guice is widely adopted elsewhere, so I'm not
> > > suggesting that Guice be relocated or forked into apache, but the Maven
> > > specific parts of that integration.... hang about... "maven specific"
> > says
> > > it all again.
> >
> > >
> > > I have always had concerns about plexus being pretty much only adopted
> by
> > > Maven as far as I can see, and essentially being a maven core
> component,
> > > except it isn't
> > >
> >
> > The Guice-based container is really no different. It uses Guice as the
> core
> > but we had to build the Plexus specific handling and that is a
> significant
> > piece of code. It is for Plexus-based code and is being used for Maven
> and
> > Nexus. Even though we will use JSR330 annotations at some point in the
> near
> > future there are some Plexus-isms that will remain. It's not straight-up
> > Guice, that simply wouldn't have worked. This code is general purpose,
> and I
> > argue that so is Aether.
> >
> > Of course Maven was our first target, but the two repository types of any
> > consequence are Maven and p2. No one here has likely ever worked with a
> p2
> > repository and likely doesn't care. p2 is critical for our work, Aether
> will
> > adopt/change/merge p2 concepts and having written the library we will
> > determine its fate and it needs to be in a place where it's accessible by
> > others is of primary importance.
> >
> > During the course of development of Maven 3.x development only Kristian
> and
> > Olivier have dug in. I honestly don't believe droves of people here are
> > going to all of a sudden start making huge contributions to the effort. I
> > want to lower the barriers for Aether's development. I believe that tools
> > like Grade, SBT and many other integrators will adopt Aether very soon.
> >
> > Having several people who haven't been even remotely involved in the
> > project over the last year tell me what we should do with the code we
> wrote
> > doesn't sit very well with me philosophically to be perfectly frank. You
> do
> > the work, you earn the merit, and therefore the right to decide the fate
> of
> > the code. You don't think that's justified or fair? At least initially
> until
> > there is a community built around it and nothing leads me to believe
> given
> > the events over the last year that the best place to grow a community for
> > Aether is Apache.
> >
> > > -Stephen
> > >
> > > Ralph
> > >>
> > >>
> > >> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote:
> > >>
> > >>>
> > >>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote:
> > >>>
> > >>>>
> > >>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> We have two major pieces that we, Sonatype, would like to merge
> into
> > >> Maven 3.x trunk.
> > >>>>
> > >>>> Are these reviewable distinctly? I only seem them mashed together in
> > >> Benjamin's fork.
> > >>>>
> > >>>
> > >>> The Guice changes are dependency changes only. All the magic happens
> in
> > >> the container implementation.
> > >>>
> > >>>>
> > >>>> The messages I'd seen so far seemed to indicate it would be heading
> > back
> > >> to Apache, before it was integrated into trunk. This caught me by
> > surprise,
> > >> and I'm disappointed that's not a consideration right now.
> > >>>>
> > >>>
> > >>> Ultimately it's going to be more like p2 so ultimately if it moves
> > >> anywhere it will be to Eclipse.
> > >>>
> > >>>>
> > >>>> On the one hand, we have a repository indexing API eventually coming
> > in,
> > >> but the repository API itself going out - that seems a bit odd. There
> > does
> > >> seem to be a lot of "Mavenisms" in the code, at least at present, that
> > would
> > >> indicate it best fits here. On the other hand, I can see the value in
> > having
> > >> a broader group participating in this effort, and in parallel
> > simplifying
> > >> Maven core to focus on more directly build-related stuff, such that it
> > makes
> > >> sense for it to be a standalone project.
> > >>>>
> > >>>
> > >>> Many other projects are going to be integrating this code and it's
> > likely
> > >> contributions from non-Maven developers will be high. I want to
> > collaborate
> > >> in easily, I want to release once a day if necessary to accommodate
> > >> integrators, I want to use best practices for fully automated
> releases,
> > and
> > >> I want to be able to update the website instantly. Some of these
> issues
> > are
> > >> in never-ending discussion mode here, and some of these things will
> just
> > >> never happen here. I don't want to argue, and I honestly believe
> Aether
> > will
> > >> be healthier for it. Maven is better here because it's adopted on
> slower
> > >> cycles and people don't pick up experimental builds. Integrators will
> > likely
> > >> be riding the bleeding edge with Aether for a while.
> > >>>
> > >>>> My main concern is Maven chasing snapshots. For someone to address a
> > bug
> > >> or feature in Maven, they should not have to dive into a 3rd party
> > project.
> > >> I don't really know what would happen to our issue tracker as a result
> > of
> > >> this move. That problem bit me in a small way with the plexus-cipher,
> it
> > has
> > >> been an historical problem with Plexus itself, and I don't think
> "anyone
> > can
> > >> have access" really mitigates it. When 3.0 is still struggling for a
> > final
> > >> release, fragmenting issue tracking, communication and the limited
> > >> documentation would seem problematic.
> > >>>
> > >>> I believe this is a non-issue. 3rd party dependencies are a fact of
> > life,
> > >> Maven is no different then anything else in the world. Everyone has to
> > deal
> > >> with snapshot dependencies or other dependency problems in lots of
> > projects.
> > >> Again I think Aether will be healthier having more external parties
> > >> involved. For working on a library it's honestly nice not having all
> the
> > >> overhead Apache brings to the table. Apache is great for overarching
> > >> products like Maven, but not so much for a sub-parts. Maybe if Apache
> > >> evolved in its approach to development I might think differently in
> the
> > >> future but that's not the experience now. We need to respond very
> > quickly to
> > >> users and integrators.
> > >>>
> > >>>>
> > >>>> From a technical standpoint - I'd need more time to review, if
> > >> applicable. Knowing that Benjamin does good work, I'd expect it's
> > superior
> > >> to what we have and worth moving forward with, and agree with doing
> that
> > >> soon so that the end is in sight for 3.0. I spent a lot of time
> > reviewing
> > >> Mercury to no avail (as you similarly highlighted in your blog post),
> > but
> > >> perhaps some of the comments still apply. At a glance, my first
> comment
> > is
> > >> that I can't see where the line is between the Maven bits and the
> > generic
> > >> bits. For instance, if I wanted to change how the local repository
> works
> > -
> > >> is that pluggable from Maven, or wholly within the library?
> > >>>>
> > >>>
> > >>> You can look at the demo to see how all the pieces fit together:
> > >>>
> > >>>
> > >>
> >
> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java
> > >>>
> > >>>> I really only see the question of the location of the development to
> > >> decide. My opinion would be to bring it here, alongside the indexer,
> as
> > a
> > >> subproject.
> > >>>
> > >>> I truly believe more people will be involved in Aether if it's not
> > here.
> > >> I don't believe it's in the best interest of the development of Aether
> > to be
> > >> at Apache. If I'm wrong we can move it in the future but it honestly
> > doesn't
> > >> make any difference now from a practical stand point.
> > >>>
> > >>>> Get all the effort on getting 3.0 out focused in one place, but have
> a
> > >> clear scope to where they might go later. However, I'm not putting up
> > any
> > >> roadblocks here. The time I would have had to work on this over the
> last
> > few
> > >> years since trunk split off has pretty much evaporated. I'd love to
> get
> > back
> > >> into this particular code if it ended up somewhere I could contribute.
> > But
> > >> for now, I mostly want to encourage those who are still here to think
> > >> through the implications for developing Maven.
> > >>>>
> > >>>
> > >>> Fair enough.
> > >>>
> > >>>> Thanks,
> > >>>> Brett
> > >>>>
> > >>>> --
> > >>>> Brett Porter
> > >>>> [hidden email]
> > >>>> http://brettporter.wordpress.com/
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: [hidden email]
> > >>>> For additional commands, e-mail: [hidden email]
> > >>>>
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Jason
> > >>>
> > >>> ----------------------------------------------------------
> > >>> Jason van Zyl
> > >>> Founder,  Apache Maven
> > >>> http://twitter.com/jvanzyl
> > >>> ---------------------------------------------------------
> > >>>
> > >>> A language that doesn’t affect the way you think about programming is
> > not
> > >> worth knowing.
> > >>>
> > >>> -— Alan Perlis
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > First, the taking in of scattered particulars under one Idea,
> > so that everyone understands what is being talked about ... Second,
> > the separation of the Idea into parts, by dividing it at the joints,
> > as nature directs, not breaking any limb in half as a bad carver might.
> >
> >  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
> >
> >
> >
> >
>