The very real problem is projects that may be aggressive in adopting
new versions of Maven and/or the model and only deploying newer
versions of POM. Users with older versions of Maven will not be able
to consume those POMs.
The next couple version of 2.0.x need to be taught an adaptive way of
dealing with different versions/formats of the POM. What Shane has
created will work but the back porting the property model system into
2.0.x is going to take a little creativity. Generating new forms of
descriptors like we did moving from 1.x to 2.x was crude and we cannot
reach everyone's repositories. We have learned this is generally not
very practical.
The pluggable transformers that can take a model from one version to
another can be picked up dynamically by older versions of Maven to
cope with future changes. It simply boils down to transforming one set
of properties to another. We will likely at least see 2.0.11 and
2.0.12 before Maven 3.x and newer forms of the POM are final so we'll
need to work this out.
On 22-Nov-08, at 2:05 PM, Paul Benedict wrote:
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
