+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
