On 8/4/10 11:03 AM, Jason van Zyl wrote:
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:
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.
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.
All due respect, but that dodges the question of separating and
standardizing the API from the implementation. It also dodges the
discussion about who sets the design of the repository format and the
API spec used to access it.
You're asking the Maven community to give up one of its greatest
creations - the repository format that has become a de facto standard -
and become completely dependent on a project whose future may be
uncertain. It's easy to talk about companies as these fixtures in the
market, but the fact is we're talking about giving complete control over
the Maven repository API / format to a start-up. Start-ups are not known
for their stability. Then, the company in control _may_ decide
(unilaterally) to move the whole shebang to Eclipse. There's absolutely
no role for Maven developers in this model, unless they go out and
re-establish their merit on a new project.
I'm not talking about the merit to contribute implementation details -
though the ASF concept of non-expiring merit argues strongly against
losing access to that. What I'm talking about is the right to contribute
to the design of the repository format, API, and SPI (now that I notice
that's separate from the API). The language we use to share artifacts
and metadata should not be under the sole control of a private entity.
Sure, there haven't been too many contributors to Maven 3. But how much
of that has to do with the velocity of work done and paid for by
Sonatype, the dramatic and repeated shift in direction by those paid
contributions (mercury for example), the need to chase code from SVN to
GitHub, to still other GitHub repositories, and the lack of discussion
of the design of any of it?
It makes me uneasy to see how much this has become a skunkworks type of
project, where much of the development takes place behind closed doors
and then gets dumped on the Maven community.
Maven contributors established the foundational concepts (and code, from
what I can tell) for Aether; Aether is a refactoring of that essential
design and format. If you expect Maven to use Aether, then the Maven
community deserves some say in the future of the format and API. That's
my opinion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
