On 07/08/2010, at 1:23 PM, Jason van Zyl wrote: > > Ideally there should be no API leakage from Aether. As part of the plugin API > we should provide access to whatever resolution functionality we feel is > necessary to expose and hide Aether. Initially a few attempts are likely > needed and I might try using the Aether API directly. I honestly don't think > using Aether APIs directly would be a great idea and really I think we > exposed way too much previously. It boils down to answering the question: > what do plugin developers actually need? Walk the dirty tree, walk the > resolved graph, filter, I don't know yet. Maybe I'm wrong and this might just > end up being the complete replication of the Aether API at which point I > don't know if it makes sense to try and hide it. This is why we preserved the > use of the old API because this stuff just takes a while to figure out. Even > us working full-tilt it's taken a while. I would like to limit drastically > what's in the plugin API for dealing with artifact resolution.
Ok, that's making more sense. So it's still hidden behind the old resolver APIs. In future versions, we offer a Maven API to expose whatever is used internally that is more capable of some of its features. If a plugin developer is not satisfied that might code against aether directly, and that would be completely decoupled from the Maven version, reresolve, etc. That's my main concern from a 3.0 PoV. > >> Other new features have been stalled waiting for a 2.1/3.0 release so that >> we can change the POM to properly utilise them. Any attempt to fix bugs >> would have been fruitless because there was always another thing out there >> that was going to replace the current code - in fact I've been trying to get >> you to open up your declared plans on artifact handling since we met at >> JavaOne in 2007. I can think of a handful of committers here that had a >> crack at Mercury and ultimately had their time wasted on a moving target. > > Sorry, but I think that's nonsense. Oleg was not locked in a vault. If > someone actually worked faster then us and implemented something we stated we > were going to do I would have been fine with it. It should never be a race to a concurrent working implementation. Circumstances and frustration were at play in that, but I felt like I did what I could to get involved in Mercury. But anyway that's history, I just wanted to illustrate why a lack of activity here is not always that clear-cut. > But I don't think anyone actually understands how much work it is. I don't > know how exactly things are going to look ultimately but in the case of > Aether we just went nuts for 8 weeks. The sequence of events was probably > required. I didn't know how hard it would be and it proved to be hard. I > honestly don't think design by committee works for this stuff. I don't disagree at all. > Much like parallel builds, it just drops out from a couple people doing a lot > of work and then there's something to look at. Dan dropped in the first > implementation and he just did it. No one much batted an eyelash. Kristian > then picked it up. After looking at Aether I think people will agree it's the > best starting place we've had. Nothing is perfect, but I think it's a good > place to start. And doesn't that show that you could have done the same thing with Aether? :) >> It is not an easily reversible step, and I want to ensure that anyone that >> wants to get an improvement into Maven doesn't have to navigate the >> different controls and infrastructure of another project. > > Unavoidable. We're not going to bring in everyone other dependency and any > developer worth their salt can figure out how to pull in sources for > dependent projects. Aether is all JIRA and Confluence it's not a big leap for > anyone here. The barrier is not and never will be the infrastructure, it's > people's time and willingness to contribute. > I continue to disagree. Time/willingess is #1, but the pain of tracking two of everything takes away from the time and willingness one has. We've seen it too many times before. >> I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it >> drove me crazy. > > It's no different now. We still have Modello and now Guice which none of you > have any control over. We are very fortunate to have Stuart working with us > at Sonatype who is a committer but by your measure this is worse. Totally > different infrastructure and no access. Guice is an improvement because it reduces our exposure. Guice itself is a fairly known quantity, so we may only have to deal with issues in the shim or the rare one in Guice, not having to maintain all of plexus. I went through exactly the same thing with the plexus-spring bridge in Archiva, and it made things much easier (and I hope we might consider using the guice bridge there too). I expect us to work at improving the Maven APIs to use Guice directly, but other than that the hard work has been done (thanks!). There's no reason for Maven to need to make significant enhancements to the underlying stuff in the future. Aether would be a completely different story. Any time an MNG issue could be filed that means I need to file an AETHER issue, I consider that a problem. Apart from the next few weeks, I think that'll be rare for the shim. It's probably 1/3rd of open MNG issues for Aether though. Moving on, it seems you've answered my technical concerns from a Maven3 PoV, so I'm not objecting to this landing on trunk as is. I'll repeat that I remain reluctant to see an important part of the project's scope heading out of its governance. I can't force it to happen, but I'd again strongly urge you to reconsider hosting the core part as a subproject here (and by all means bring Alin on board as the other main contributor to it so far). I would gladly help with that. Continue to use github and whatever else forked from that repo to work on improvements that aren't important to Maven with others. If in the future it starts to shape like something that is quite stable from Maven's point of view, and the scope outgrowing it, then graduate to a TLP, Eclipse, or wherever seems appropriate. I know the tone of this thread in parts hasn't been particularly helpful and maybe isn't conducive to wanting to do that. A lot of that is knee-jerk stuff that should die down moving forward as people get on with it. I could be wrong, but I still think that if you ran a poll of committers who have a stake in Maven3 development, you'd find a preference for hosting it here. If I'm right, I think that's worth taking into consideration. 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
