One of our more capable Mavenistas has figured out what is going on
here, but there's still a nasty transitive-dependency bug at large.
In the dependency-management POM, the dependency was declared as
follows:
<dependency>
<groupId>com.somewhere.apple</groupId>
<artifactId>platform-logging</artifactId>
<version>${project.version}</version>
</dependency>
We didn't realise that this property would be evaluated in the context
of each POM rather than the POM in which it was declared. Hence when
this dependency is reference by groupId and artifactId alone, it adopts
the version of its POM, rather than the version of the POM which
contains the dependency-management section.
What is more disturbing is that even though we had specified an explicit
version for the artifact in banana-api (see below), when the transitive
dependency is reported to banana-api-impl, it uses the version from the
dependency-management section rather than the one specified in
banana-api. Surely the transitive dependency's version shouldn't be
overridden?
-----Original Message-----
From: Michael Guyver
Sent: 09 September 2009 20:36
To: [email protected]
Subject: SNAPSHOT POM inheritance breaks dependency-management
Hi there,
I've got a strange problem with the versioning of snapshot artifacts
which seems to be affected by the version of POM declared as the
project's parent. Hopefully the following example will explain what's
happening.
I have a base-POM called, say,
com.somewhere.apple:apple-pom:10.0-SNAPSHOT, which declares the version
of all the projects in the build in a dependency-management section. So
I might declare the version of a project to be used in the build (and
which will be built as part of the build-cycle) as:
com.somewhere.apple:platform-logging:10.0-SNAPSHOT
Nothing too controvertial so far, hopefully.
The weirdness arises as follows. I have a hierarchy of POMs which are
mostly declared as 10.0-SNAPSHOT:
com.somewhere.apple:deps-pom:10.0-SNAPSHOT <-- dependency-management POM
\
\ (inherits above)
\
com.somewhere.apple:apple-pom:10.0-SNAPSHOT <-- simple multi-module
POM
\
\ (inherits above)
\
com.somewhere.banana:banana-pom:1.0-SNAPSHOT <-- POM: note version
|\
| \ (inherits above)
| \
| com.somewhere.banana:banana-api:1.0-SNAPSHOT <-- note version
|
+-com.somewhere.banana:banana-api-impl:1.0-SNAPSHOT <-- note
version
In the root "deps-pom" I have a project called platform-logging, and
both its dependency-management version and build-version are declared as
10.0-SNAPSHOT, ie: anything depending on it should use 10.0-SNAPSHOT,
and the version being built is 10.0-SNAPSHOT.
However, in the the banana-api project, this fails to pick-up the
dependency declared in deps-pom (10.0-SNAPSHOT) and instead tries to
rely on 1.0-SNAPSHOT. Why does this happen? Why is it substituting its
(SNAPSHOT) version for the version declared in deps-pom?
I've hacked a fix to this by explicitly putting in the version in the
dependency section of banana-api.
More weirdness though: the project banana-api-impl (also inherits
com.somewhere.banana:banana-pom:1.0-SNAPSHOT) depends on banana-api.
Despite the explicit version stipulated in banana-api, banana-api-impl
tries to rely on 1.0-SNAPSHOT, not 10.0-SNAPSHOT (as you might expect).
I suspect this is another manifestation of the same problem, and fix the
original problem and this will go too. However I would have thought that
the transitive dependency mechanism would have used the version declared
in banana-api.
I'm sorry if this is horribly impenetrable, but we're at a loss to see
why the banana-* projects fail to use the correct dependency version.
Indeed, a run of help:effective-pom shows that it substitutes its
version (1.0) for all other child projects of apple-pom (which are at
10.0). Go up a directory to apple-pom, run help:effective-pom and all is
well.
Please help!
Cheers
Mike
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
