Hello, As a followup on my original mail, I also started debugging the Maven internals. I came to the conclusion that properties defined in profiles, are not injected into the Maven model of transitive dependencies, just before the interpolation is executed.
Attached you can find 2 POM files that I use with Maven 2.0.9. The file a-pom.xml contains the base project depending on junit 3.8.1. In b-pom.xml, I depend on project 'a', but I want to redefine the version of junit to 3.8.2. If I override the value in the properties section, everything is OK, but if I redefine it via a profile, it is not picked up. Install project a in your local repository, and then run mvn dependency:resolve on project b. Although I redefined the junit version to 3.8.2, this is my output: [INFO] The following files have been resolved: [INFO] be.atriso.test:a:pom:1.0-SNAPSHOT:compile [INFO] junit:junit:jar:3.8.1:compile Is this a bug, or is this intended behaviour? If this is a bug, I found the reason why it fails. In the Maven 2.0.9 codebase, there are 2 callers to DefaultMavenProjectBuilder.buildInternal(...). The first, DefaultMavenProjectBuilder.buildFromSourceFileInternal(...), is used when the POM of the current project is processed. The second is DefaultMavenProjectBuilder.buildFromRepository(...) and is used when resolving the transitive dependencies during the Mojo execution. The first caller is used when Maven is bootstrapping. When we enter buildInternal(...) via this path, the config object passed in here contains a reference to the profileManager. When we enter buildInternal(...) via the second path (buildFromRepository(...) ), the config object does not have a reference to the profileManager and no profiles will be injected into the model before the interpolation is executed. Any comments? Ringo > -----Original Message----- > From: De Smet Ringo > Sent: woensdag 10 december 2008 12:49 > To: [email protected] > Subject: Version property in root POM & multi-level > dependency resolution > > Hello, > > [Repost from users list, hoping to get more in-depth answer here] > > I am busy creating an easy Maven2 setup for a 200+ module > system, both targeted to an easier release and an easier > development setup. It is a multi-level system, with common > modules, service modules and presentation (web-ui) modules. I > will use a simplification of this setup in this mail: > > pres.d -> srv.a -> common > > I also created a 'root' pom containing common build > instructions and a property > <ver-release>[9.10,9.11)</ver-release>. The root POM is > released as version 9.10.0. All other modules refer to this > versioned root POM as their parent POM. > > All modules in a release 9.10 (current release) have > 9.10-SNAPSHOT as their version. When I create a release, I > use the properties releaseVersion and developmentVersion to > make builds numbered 9.10.0, 9.10.1, ... and then fallback to > 9.10-SNAPSHOT during development. The dependencies on other > internal modules are specified using the ver-release > property. This means that every module depends on the latest > released version of its dependencies, e.g.: > > pres.d:9.10-SNAPSHOT -> srv.a:9.10.3 > srv.a:9.10-SNAPSHOT -> common:9.10.2 > > Making releases of modules gives me a complete versioned > hierarchy since I create a module release containing a > release-pom.xml with all the version ranges resolved to > actual version. So far so good if you look at it from a > release viewpoint. > > The problem arises trying to get my development setup in > place. Developers usually have to change code spanning > multiple modules in multiple layers. Let's assume that, to > implement a certain feature, a developer needs to change > pres.d, srv.a and common. In such a setup, I would like > pres.d:9.10-SNAPSHOT to depend on srv.a:9.10-SNAPSHOT, and > srv.a:9.10-SNAPSHOT to depend on common:9.10-SNAPSHOT. > > Well, since the indicated version is defined as aproperty, I > created an active profile in my settings.xml and redeclared > the ver-release property in there. Now comes the point where > I think Maven is failing. Here is the output of "mvn > dependency:resolve" of pres.d: > > [INFO] The following files have been resolved: > [INFO] be.telenet.test:common:jar:9.10.4:compile > [INFO] be.telenet.test:srv.a:jar:9.10-SNAPSHOT:compile > > The dependency resolution correctly resolved the dependency > from pres.d on srv.a to 9.10-SNAPSHOT, but it seems to ignore > my overridden property and resolved the dependency from srv.a > on common to the latest resolved version. All deployed > SNAPSHOT versions of the POMs contain the version property, > so I would expect this property to resolve to my overridden > value for the complete dependency chain. > > Where in the code are properties resolved to actual values > when building Artifact objects? Any other comments? > > Ringo ************************************************************* Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes �ventuelles peuvent contenir des informations confidentielles et/ou prot�g�es par des droits de propri�t� intellectuelle. Ce message est adress� exclusivement � son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou compl�te sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez re�u ce message par erreur, veuillez pr�venir l'exp�diteur du message et en d�truire le contenu. *************************************************************
<project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>be.atriso.test</groupId> <artifactId>a</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <name>Project A</name> <properties> <ver-junit>3.8.1</ver-junit> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${ver-junit}</version> </dependency> </dependencies> </project>
<project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>be.atriso.test</groupId> <artifactId>b</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <name>Project B using A</name> <dependencies> <dependency> <groupId>be.atriso.test</groupId> <artifactId>a</artifactId> <version>1.0-SNAPSHOT</version> <type>pom</type> </dependency> </dependencies> <profiles> <profile> <id>override</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <ver-junit>3.8.2</ver-junit> </properties> </profile> </profiles> </project>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
