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 <ralph.go...@dslextreme.com>:
>> 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
>>>> br...@apache.org
>>>> http://brettporter.wordpress.com/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>> 
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>> 
>>> A language that doesn’t affect the way you think about programming is not 
>>> worth knowing.
>>> 
>>> -— Alan Perlis
>>> 
>>> 
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

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

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



Reply via email to