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 first are the Guice changes that we've been talking about for a while, > and the second is the introduction of Aether which is our second attempt at a > stand-alone repository API. The PMC is aware of Aether as Brian reported it > in our quarterly report to the Apache Board, but other developers who are not > on the PMC and the community in general might not know much about it. Actually it wasn't. I think the only reason I know about it is because you told me directly and because I follow your twitter feed. I hope it's clear that world -> PMC -> developers is not an optimal direction for getting folks here involved. > > I just posted an entry giving a very high level description: > > http://www.sonatype.com/people/2010/08/introducing-aether/ > > There is a resources section at the bottom of the post for those interested > in the sources, issue tracking, wiki and mailing lists. As part of some of > the research we are about to embark on with Daniel Le Berre, Aether will > likely look more like p2 as time passes and as a final resting place the > Eclipse Foundation is more likely then Apache. I know people will ask so I'm > answering that now. Sonatype is just about to fully move Tycho over the > Eclipse Foundation and we want to see how that goes. If that works, then > M2Eclipse is next, and then Aether will follow. > > At any rate we would like to merge these changes in and make plans to release > 3.0-beta-2. > > So please let us know if you have any objections. 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. I'm torn on this. For starters, there's clearly a need for something better. One of the first tasks I created on Maven 2 (over 5 years ago now - http://jira.codehaus.org/browse/MNG-140), was to re-do maven-artifact. In the end, I never got to that task and instead built a lot on top of it before we decided to ship Maven 2, and we suffered for not revisiting it. So, bear in mind I have a fair emotional investment in the code that just got wiped away :) 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. 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. 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? 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. 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. 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
