No. I wouldn't see any model or deployment changes occurring in 2.0.x.
However, since the deploy plugin delegates to Maven's artifact
mechanism in 2.1.0, it can do the extra adjustments itself if there
were a new model version introduced.
- Brett
On 25/11/2008, at 6:51 PM, nicolas de loof wrote:
Does this mean maven 2.0.10+ will require a new plugin attached to
(pre)deploy phase to generate a 4.0.0 compatible POM ?
2008/11/25 Brett Porter <[EMAIL PROTECTED]>
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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
