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