I'll try and sum up some things I expressed on IRC, in response to Brian's message.
I'll be clear upfront that we have no right to tell Sonatype where they host code they wrote, so let's focus on the impact for Maven itself. Equally so, no matter how generous they are with a donation: solutions that move project scope or code, or tie the project to a single company or individual - are close to a non-starter IMO. On 05/08/2010, at 12:04 AM, Brian Fox wrote: > The key question here is why is this different than ANY other > dependency we choose to use that's not at Apache? It's different because it's changing the scope of the current Maven project, and because of the increased likelihood in having to chase code across projects to develop Maven. The problem will always exist, but we can do what we can to narrow our exposure. It would make my occasional stint as Chief JIRA Monkey even more annoying :) > > I for one would love if anyone consuming and producing artifacts for > Maven repos could use the same code easily. Having all these > permutations makes a mess of the repos when files and metadata aren't > updated correctly. +1, and I don't think anyone is arguing that. > > It's obvious that projects other than Maven won't use the code in > Maven to do it, evidenced by the fact that they don't today. How much of that is crap API, poor documentation, etc. vs. the other factors though? > Having > this api code in a neutral location makes that hurdle, even if it's a > mental one, non-existent. Projects that "compete" won't use each > other's code, but everyone uses the same external dependencies > already. (think about logging...everyone uses log4j, slf4j etc. If we > made log4m and dropped it in maven's scm, would Gradle, Ivy, Buildr > use it? Doubtful... at the same time, would the Maven project start > depending upon the code in gradle for resolution? Also doubtful.) What you touch on also goes in the other direction. The reason they'd not do that, assuming it was well coded and accessible, is lack of control. That could be a problem here. I'm not arguing against the value of being separate to increase the scope of the library. I can see where that is a potential growth area for it outside of Maven, and while I don't entirely agree with some points raised, I recognise the concerns about being able to collaborate on all that inside Maven. But what I most want resolved is the concern of losing control over the bits Maven has today. I would ideally like to see the API Maven uses, and expects plugins to use, here. I would like to see the Maven implementation for a local repository and a Maven-format remote repository here. The rest matters far less to me. Is there any scope for a trimmed down API here, that is pretty much final now, and a wider-scoped Aether (that depends on the Maven API and legacy implementation as a basis) elsewhere? Or are there other alternatives that could be suggested? There are a number of reasons that I don't like about how we got here, but we've no choice but to put them behind us and figure out the implementation details. We all agree so far that refactoring the API is a good thing that needs to be available in Maven 3.0. I think we're a bit short on details of what that really means for Maven developers, and for Maven plugin authors after 3.0, though. Thanks, Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
