I don't see any veto here.
Perso, I like this change (at least/especially the plexus-guice stuff).
Concerning the other part, I didn't work enough and don't have enough
time to work on this part of the project to have a clear idea.

As I haven't seen vote here , I push my +1.

And IMHO, earlier thoses changes will be here and released better it will be

And btw, your position regarding eather codebase place can be review later.
If the issue is only long release process etc.., you can change when
the codebase will have reach a good stability...

2010/8/4 Jason van Zyl <ja...@sonatype.com>:
> 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
>
>
>
>



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

Reply via email to