I like the idea of deploying multiple POM files. It is very in line with deploying multiple hash codes.
Another solution is to deploy one POM that contains both the 4 and 5 signature. You can do this using XSD namespaces. The namespace of the root element can be whatever POM version you want, and then have inner children that have a different POM versions. On Sat, Nov 23, 2013 at 6:00 PM, Robert Scholte <rfscho...@apache.org>wrote: > A couple of months ago I started with a patch for Modello[1][2] which > should make it quite easy to generate a single Reader and Writer with > support for different versions, with respect to all the existing checks. > This is one of the requirements which must be fixed before we can start > implementing the changes to the model. > However, I don't have commit rights on the Modello-project, so I could use > some help to get these changes merged. > I will review my work to see if everything is there and if the naming is > correct. > > Robert > > > [1] https://jira.codehaus.org/browse/MODELLO-4 > [2] https://github.com/rfscholte/modello/tree/modello4 > > > Op Sat, 23 Nov 2013 23:44:56 +0100 schreef Stephen Connolly < > stephen.alan.conno...@gmail.com>: > > Before I forget, here are some of my thoughts on moving towards Model >> Version 5.0.0 >> >> The pom that we build with need not be the pom that gets deployed... >> thus the pom that is built with need not be the same format as the pom >> that gets deployed. >> >> Only with <packaging>pom</packaging> do we actually need things like the >> <plugins> section in the deployed pom, because it is a reality that for >> noo-pom packaging we just want the transitive dependencies. >> >> Now there is the <extensions> issue where you might be registering a >> different file type that has different rules with respect to the >> classpath... but I am unsure if we actually consider those when evaluating >> the dependency tree... and in any case, once we accept that the deployed >> pom is not the same as the pom used to build (for non-pom packaging at >> least) we can transform that dependency tree using the exact rules that >> have to be known at build time thus closing the extensions issue. >> >> For projects with <packaging>pom</packaging> in fact we are only deploying >> smal files so perhaps we can deploy two pom files... the one that exposes >> the standard dependency stuff and then a second one that is used for build >> inheritance. >> >> My vision is thus that we deploy between 2 and three pom files for every >> project. >> >> For jar/war/ear/... we deploy: >> * a modelVersion 4.0.0 pom as .pom (only lists dependencies) >> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows >> for new scopes) >> >> For pom we deploy >> * a modelVersion 4.0.0 pom as .pom (only lists dependencies) >> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows >> for new scopes) >> * the pom itself >> >> When building a pom, your parent pom must be of a modelVersion <= your >> modelVersion. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers, Paul
