I'm not sure even rolling in changes to support this in 2.0.11+
answers the question. We're still having trouble getting people up
from 2.0.6 type versions, and we're still supporting Maven 1 clients.
A forced upgrade, even over time, seems impractical at this point.
A lot of good suggestions in this thread that I agree with, though.
Here is what I would propose:
1) start deploying artifactId-version-pom.xml to the repository as the
original, unmodified POM artifact alongside the 4.0.0 versioned POM file
2) continue deploying 4.0.0 versioned .pom files as we do now. We
could potentially strip these down to just a subset of the information
that is actually used by client tools today
3) use tools to produce those 4.0.0 POMs in the future (or repository
managers), much like the m2 -> m1 situation that is available today
These steps give us enough to start incrementing the modelVersion
already, and the code is already available in various places.
4) continue to map out a future where repository metadata is unified,
extensible, and business logic like transitive dependencies
algorithms, inheritence and interpolation are not wound into it, for
new tools to take advantage of. Probably use a new repository layout
(even if the layout is the same) as a hint to Maven for how to treat
it so it can be cleaned up
This seems pretty much the direction everyone is headed, right?
- Brett
On 25/11/2008, at 5:08 AM, Shane Isbell wrote:
On Mon, Nov 24, 2008 at 12:00 AM, Gilles Scokart
<[EMAIL PROTECTED]> wrote:
A big +1. Changing the published poms format is very impacting. Not
only for the maven client, but for all tools that are using the
repository as a server (ivy, buildr, maven proxies & repository
managers, etc...).
It may be impacting but these tools should be transforming poms to a
format
that they internally understand and need, not directly relying on
the pom
format itself, as that design will make it nearly impossible to
upgrade
versions. For Java based clients, a lot of the transform work is
already
done for them in maven-shared-model. They just need to create a
transformer
for transforming from the canonical format to their internal format.
That
should give a start.
And none of this would occur overnight. For maven 2.0.x, it is not
trivial
to make the changes. So this is more of a long-term thing that other
tool
developers need to start putting some brain-cycles into.
Shane
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
