Some comments/questions on the doc Jason mentioned. Skipping entirely
the question of "when" since that's a very different discussion.
There are several plugins that are using the current artifact
resolution code that will not be supported (please see the Mercury
section below).
If the old artifact interfaces were available as a facade for Mercury,
even though the resolution would potentially be different would it work?
h3. POM changes
There are many changes that users have requested in the POM, in
addition to wholesale formatting changes. Acommodating these
requests is a little tricky
because we need to support different versions simultaneously so that
if projecta A builds with 2.0.x, project B can consume the project A
POM using 2.1.x.
We just need some way to easy support multiple versions and support
mediation between the different versions.
Consumption is only as a dependency - we should be able to translate
POMs back to 4.0.0 (or even a subset of that) required for resolution.
In this instance it could also be made concrete so the rest of the
project building is not needed for metadata resolution.
You also need projects built with 2.1.x to be consumed by 2.0.x.
h3. Embedding
Full embedding of the Maven core is a major feature of the 2.1.x
line. The embedder was created primarily for IDE integration and is
now being consumed by m2eclipse, Mevenide and IDEA,
and q4e :)
h3. Mercury
Mercury is a replacement for the current Maven Artifact subsystem,
and a complete replacement for the HTTP and DAV portions of the
existing transport.
How do you plan to handle non-HTTP transports, particularly for
deployment?
h3. Integration and promotion of scriptable plugins
What does this mean exactly? Making jruby plugins work OOTB, for
example?
- Brett
