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]
