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
