maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Merging in our Aether and Guice changes to Maven 3.x
Date Wed, 04 Aug 2010 15:03:47 GMT

On Aug 4, 2010, at 10:35 AM, John Casey wrote:

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

Once the API is set for Aether it will be supported forever. Essentially the Eclipse way of
supporting APIs. Just like we're supporting the old Artifact APIs now with Aether being the
backing implementation. We're sensitive to external consumes.

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

It can't drift. Whatever is in place needs to be supported, all the plugins that use the artifact
resolution APIs as they stand here now still work with.

> 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
>> ---------------------------------------------------------
>> 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:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but
good ideas can't save bad people. 

 -- Paul Graham

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message