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
>
>

Reply via email to