I don't see anything wrong with POMs not being backwards compatible. If the model is 4.1, so you should have a 4.1 parser -- upgrade your Maven if necessary. Is this really any different than trying to import a Maven 1 dependency in Maven 2?
Paul On Sat, Nov 22, 2008 at 2:05 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > > > On 22 Nov 2008, at 19:52, "nicolas de loof" <[EMAIL PROTECTED]> wrote: > >> 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>. > > that will only work while you know what the transitives pulled in are. > > my point is that if foo depends on anything other than a hard single version > eg [2.3] we can never be sure what *all* the dependencies are in order to > brute-force exclude them > > such a brute-force exclude is required, and short of introducing wildcards > for exclusions backported to the 2.0.11 line, I don't see how we can write a > 4.0 pom that describes the problem > > as regards rewriting, I'm actually in favour of doing just that. I have a > plugin that rewrites pons taking out sections we don't want to make public > (build, reporting, test-scoped dependencies, the list of developers, our > internal distribution management, ...) and locking down some things so that > there are no profiles or properties... I'm toying with putting it on mojo > > we use it to prepare a pom that can be used from outside, but keeps internal > details safe > > what I'm saying is let's go farther and make the pom deployed to the repo a > more minimal pom... keeping only that which is actually needed > > - Stephen > >> >> >> 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] >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
