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