Could it be supported by a JSR ? Not a lightweight process, even considering JSR-330 was out after 6 month, but the most agnostic way to group community efforts. Aether could then be proposed as RI
2010/8/4 John Casey <jdca...@commonjava.org> > On 8/4/10 10:39 AM, nicolas de loof wrote: > >> Ivy Guys could be interested in such a "neutral" repository API, as they >> also support both m2 and proprietary repo format. >> > > Is Ivy even active still? > > I see Eclipse p2 as a better target for interoperability, but that's beside > the point. > > We're talking about mediating the way artifacts are shared in software > builds and deployments. Gradle, Ant, Ivy, Maven, Eclipse are all projects > interested in this space. Users of this sharing mechanism may come to it via > a wide variety of applications. > > Surely we can agree that establishing a standard and having everyone on the > same page contributing to a fully interoperable design would be a good > thing? We have two fairly mature designs out there, so this wouldn't be > whole-cloth design by committee. It's more of a standards board, or steering > committee, or whatever. > > Personally, I'm sick of coding against implementations without some stable > API specification I can depend on. It breeds bugs. > > > >> 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 >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >