Ivy Guys could be interested in such a "neutral" repository API, as they also support both m2 and proprietary repo format.
2010/8/4 John Casey <jdca...@commonjava.org> > On 8/3/10 2:21 PM, Jason van Zyl wrote: > >> Hi, >> >> We have two major pieces that we, Sonatype, would like to merge into Maven >> 3.x trunk. >> >> 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. >> >> 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. >> > > > There's too much in this thread that I this is a tad distracting from the > important points, so I'm replying to the top post. > > I _really_ appreciate all the work done in getting M3 into a usable form, > and in general I like the way Aether looks (I haven't had time to look into > the guice shim yet). I realize there are newer thoughts on repository design > since Maven took its swing at things, and we need to find a way to > transition forward..."transition" because we have a large legacy of > artifacts already under the Maven repository format. HOWEVER, there are a > couple things here I'm pretty deeply concerned about. > > > 1. The repository format is a Maven concept. I'd argue that it's one of > Maven's two great contributions to the world of software (the other being a > decent build tool). As such, the Maven community should have some role in > guiding the future of that format. > > If Maven relinquishes all ownership of the API and implementation for the > piece that resolves artifacts, then we have no say in the future design of > the repository Maven uses as its lifeblood. Many people who aren't Sonatype > people have spent time working on that de facto specification, and they've > shown the merit to earn a voice in guiding this API...at least, if it's > going to be billed as a Maven-compatible Repository API. > > > 2. Jason, you mentioned sponsoring a Sat4j developer to work with Sonatype > in the future to improve Aether. What effect is this likely to have on the > aether-api module? My concern here is that we're talking about releasing > Maven 3.0-beta-2 with a completely rewritten API / implementation for one of > the most pivotal parts of Maven. It's not that I don't trust Benjamin and > Kristian to produce high-quality code. > > What I'm actually worried about having Aether API drift AFTER we adopt it > in Maven. This will hamper anyone wishing to integrate with the Maven 3 > core, whether that's Maven plugin development or Maven embedding. > > > What I'd actually prefer to see is the Aether API published in some neutral > location where we have an iron-clad guarantee that we won't be locked out of > its design. Then, put the implementations wherever you think is best. IMO > the key moving forward is to establish a standard API for resolving > artifacts. IMO, this is our great failure with Plexus, that we depended > directly on a container implementation, not on a container API. > > Having a stable set of specifications define their interaction with Maven > would make plugin development and embedding MUCH better. In fact, I think > establishing this practice might be the single best contribution we can make > to Maven in the near term. > > Thanks, > > -john > > > > >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> First, the taking in of scattered particulars under one Idea, >> so that everyone understands what is being talked about ... Second, >> the separation of the Idea into parts, by dividing it at the joints, >> as nature directs, not breaking any limb in half as a bad carver might. >> >> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) >> >> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
