On Mon, Sep 24, 2012 at 8:53 AM, Stephen Connolly <[email protected]> wrote: > On 24 September 2012 12:58, Benson Margulies <[email protected]> wrote: > >> Folks, >> >> Much electronic ink was spilt on the subject of POM5. One of the pools >> of ink was created by my attempt, some months ago, to move the design >> along. >> >> I wish someone would propose a concrete next step. >> >> > Simples...
Please add this to the wiki page that I started for POM5. > > A project built with pom5 can have as its parent (if it needs a parent pom) > either a pom5 or a pom4 project. > > A project build with pom4 can only have as its parent (if it needs a parent > pom) a pom4 project. > > A pom5 project will publish a compressed dependency pom4 version of the > project. All sections other than <parent>, > <groupId>,<artifactId>,<version>,<packaging>,<dependencies> will be in the > compressed dependency pom. Dependencies in the compressed dependency pom > will be resolved dependencies based on the pom5 build extensions and any > project properties. The pom4 pom will be published as > groupId:artifactId:version:pom and the pom5 pom will be published > as groupId:artifactId:version:pom:dev (ie. with the classifier "dev"... if > somebody has a better idea for the classifier, fine with that) > > We do not currently publish poms with classifiers, so should not cause an > issue. > > When pom6 comes along it will not be a new classifier, but the same > classifier... the rule will be that a project built with pom6 can have as > its parent (if it needs a parent pom) one of a pom6, a pom5 or a pom4 > project. > > The key here is that the requirement for the pom version matching only > applies at build time. > > The only issue I remaining is where a pom5 project depends on a pom6 > dependency and the features of pom5 do not map to pom4... e.g. if pom5 > supports <provides> that will not be available in the reduced dependency > pom4 project, and the pom6 project will be pushing pom4 -> pom and pom6 -> > pom with classifier. > > To solve that issue I suggest we publish translation shims at well defined > coordinates, e.g. > > org.apache.maven.compatibility:pom:version > > this can include shims for JVM, RVM, etc > > Those shims will know how to translate a pom [version] back to any other > previous version (given a dependency resolution api, e.g. aether or such) > so the pom5 project will download the pom with classifier, see it as a > pom6, download the shim (if not already present) and convert the model back > to an effective pom5 model and away we go! > > While that could support a parent with a newer model version than the > project being built, I think it is too complex and far simpler to just > mandate that your parent's model version is <= your model version otherwise > the parent cannot assume that all the features it enables will be supported > in the child module that is inheriting from. Parent will also include > mixins. > > In its simplest form, the shims could just be XSLT templates... that has > the advantage of being cross platform... but the disadvantage of tying poms > to XML. > > I know this is a collection of ideas both I and others have had... but I > felt it was time to put it together as a single concept > > >> --benson >> >> >> On Mon, Sep 24, 2012 at 4:41 AM, Stephen Connolly >> <[email protected]> wrote: >> > Markus, >> > >> > perhaps you mis-understood my point. >> > >> > this is a hard problem, that does not mean we should shirk away... >> > >> > that does mean we have to solve it very close to right >> > >> > the great pom migration of Maven 1 to Maven 2 left deep scars... because >> it >> > got some things wrong. >> > >> > When we do the next "migration" of Maven 2/3 to Maven 4 (personally I >> would >> > prefer to call it Maven 5 so that the pom version and maven version >> align) >> > we need to get that right. >> > >> > The model version 5 pom will likely be with us for quite some time... >> > [snip] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
