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]
