1. if my project uses maven 2.x with support for POM 4.x this is just a project requirement, as the JDK version requirement is 2. if the parent has been deployed, it will be converted in 4.0.0 format, so can be read by any maven version
Not sure you understood my idea : let the POM format as a project level tool envolve, but always deploy POM (as artifacts meta-datas) in 4.0.0 format. This only requires all 4.x improvemement to ba translatable in any way to 4.0.0. In my example, globalExclusion could be translated (brute force) to exclusion on ALL <dependency>. Nicolas 2008/11/22 Stephen Connolly <[EMAIL PROTECTED]> > 1 if a pom builds with model 4.1, then you can't build with older versions > of maven > > 2 from 1 we see that if we reference a parent, that parent must be <= our > model version > > 3. if we are not using the pom as a parent, most of the information in the > pom is redundant (certainly the build and reporting sections, the > distribution management, dependencyManagement, and possibly the scm section) > > 4. perhaps classifiers are the way out, deploy a trimmed down pom with no > classifier and the full pom with a classifier of v4.1 > > that way we look for the v4.1 pom if we are looking up the parent of a v4.1 > pom, otherwise all we really care about is the license and transitive > dependencies. > > 5. what about exclusions of transitive dependencies? > > if foo depends on bar [1.1,) and excludes commons-logging:commons-logging > > what happens when bar 2.0 changes dependencies to > org.apache.commons:logging... now the exclusion from transitives expressed > in the original pom does not work any more! > > foo may not have control over bar, and if foo declares a hard dependency on > bar [1.1] to ensure it's exclusion rule is always correct, version ranges > become useless > > Sent from my iPod > > > On 22 Nov 2008, at 13:12, "nicolas de loof" <[EMAIL PROTECTED]> wrote: > > Hi, >> >> considering the issue with a new modelVersion, that would not be readable >> by >> previous Maven versions, >> What about enhancing the deploy plugin to rewrite the POM that gets >> deployed >> as 4.0.0 ? >> >> example : suppose we create a new <globalExclusion> element in >> modelVerison >> 4.1.0. This could be translated to setting the exclusion to ALL >> dependencies >> in the POM, and writing this one back as 4.0.0. Not very nice, but who >> cares >> about the beauty of POMs on central ? They are use by maven as metadata >> sources, not by human beeing. only the POM in project SCM has interest for >> humans ! >> >> This requires 4.x modelVersion to be translatable to 4.0.0, but this could >> introduce some interesting enhancements to POM that are blocked today. >> >> 2nd Idea (more complex) : could a maven extension post-process the POM ? >> example : >> My (custom) POM uses a dedicated namespace for some extension feature : >> >> <project> >> ... >> <ext:globalExclusion xmlns:ext="someURI" >> artifact="commons-logging:commons-logging"> >> ... >> <extension> >> <groupId>org.apache.maven.extensions</> >> <artifactId>globalexclusion</> >> <version>..</> >> <extension> >> </ >> >> Note : I suppose the default parser will ignore this unexpected <ext: >> element. >> >> after parsing this POM, globalexclusion extension, that implements some >> PostProcessor API could modify the parsed Model object, and in my example >> add an exclusion to all declared dependencies. >> >> Just some week-end ideas ;) >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
