using dependencyManagement would solve my problem for the dependencies, but due to my project requirements I still need to use a property in the parent <version>, which is not managed by dependencyManagement.
>From what I can see maven doesn't have any problem in replacing properties in >the <parent> block of the current pom, but it does when it retrieves the pom >of a dependency from the repo to which it was previously downloaded when >building from the root. This pom taken from the repo has a property in the ><parent> section, and contrary to what maven does for the current pom maven >doesn't replace properties here. My issue would be solve if the poms where installed into the maven repo with the properties already replaced by their value, or if it replaced properties in the poms retrieved from the repo to calculate transitive dependencies. ----- Original Message ---- From: Stephen Connolly <[email protected]> To: Maven Users List <[email protected]> Sent: Wed, October 28, 2009 11:30:37 PM Subject: Re: maven doesn't filter dependencies defined in pom 2009/10/29 Stephen Connolly <[email protected]> > property substitution is not supported in > > /project(/parent)?/version > > 2009/10/29 Pepe Perez <[email protected]> > > Hello, >> >> This is the situation I'm in. >> >> I have this structure >> >> pom.xml (root) >> |_ pom.xml (module A) >> |_ pom.xml (module B) >> >> These are (excerpts) of the poms >> >> pom.xml (root) >> <groupId>rootGroupId</groupId> >> <artifactId>rootArtifactId</artifactId> >> <packaging>pom</packaging> >> <version>${rootGroupId}</version> >> >> <modules> >> <module>moduleA</module> >> <module>moduleB</module> >> </modules> >> >> <properties> >> <moduleAGroupId>1.0-SNAPSHOT</moduleAGroupId> >> <moduleBGroupId>1.0-SNAPSHOT</moduleBGroupId> >> <rootGroupId>rootVersion</rootGroupId> >> </properties> >> >> pom (module A) >> >> <parent> >> <groupId>rootGroupId</groupId> >> <artifactId>rootArtifactId</artifactId> >> <version>${rootGroupId}</version> >> </parent> >> >> because maven does not know rootGroupId until it fetches the parent, it does not know what parent to fetch, so it does not know moduleAGroupId either > <groupId>moduleAGroupId</groupId> >> <artifactId>moduleAArtifactId</artifactId> >> <packaging>pom</packaging> >> <version>${moduleAGroupId}</version> >> >> pom (module B) >> >> <parent> >> <groupId>rootGroupId</groupId> >> <artifactId>rootArtifactId</artifactId> >> <version>${rootGroupId}</version> >> </parent> >> >> <groupId>moduleBGroupId</groupId> >> <artifactId>moduleBArtifactId</artifactId> >> <packaging>pom</packaging> >> <version>${moduleBGroupId}</version> >> >> <dependencies> >> <dependency> >> <groupId>moduleAGroupId</groupId> >> <artifactId>moduleAArtifactId</artifactId> >> <version>${moduleAGroupId}</version> >> <dependency> >> </dependency> >> >> cd root >> mvn install >> >> ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESSFUL >> [INFO] >> ------------------------------------------------------------------------ >> >> cd moduleB >> mvn install >> >> [WARNING] Unable to get resource >> 'moduleAGroupId:moduleAArtifactId:${moduleAGroupId}' >> from repository central (http://repo1.maven.org/maven2): Error >> transferring file: Server returned HTTP response code: 500 for URL: >> http://<pom_maven_repo_location> >> ------------------------------------------------------------------------ >> [ERROR] BUILD ERROR >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Error building POM (may not be this project's POM). >> >> >> Project ID: moduleB >> >> Reason: Cannot find parent: moduleA pom for project: moduleB >> >> This is happening because when building moduleA its pom file is >> installed in the maven repo without filtering, i.e, as it is with ${}. >> When the pom is retrieved to satisfy moduleB dependency on moduleA it's >> retrieved as >> >> <groupId>moduleAGroupId</groupId> >> <artifactId>moduleAArtifactId</artifactId> >> <packaging>pom</packaging> >> <version>${moduleAGroupId}</version> >> >> where ${moduleAGroupId} is not instanciated, hence the error. >> >> My question is: >> 1. Could I force maven to store the pom files **filtered** or >> 2. How can maven be forced to instantiate ${moduleAGroupId} upon >> retrieval from the maven repo so moduleB dependency can be satisfied >> 3. What other alternative do I have to solve this scenario without >> giving up using ${} in <version> >> > why do you need to use properties for /project(/parent)?/version if you use the release plugin, it will update those correctly, and as well will likely update the dependencies for you. It would seem to me that your use case would be better served with a dependencyManagement section in the root pom. then you can omit the version in the dependency sections of each child pom such that the only versions specified are in /project(/parent)?/version Also, if you are going to release all of them in the same go, you should note that /project/version is inherited from /project/parent/version my solution would be as follows: pom.xml (root) <project> <groupId>rootGroupId</groupId> <artifactId>rootArtifactId</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <modules> <module>moduleA</module> <module>moduleB</module> </modules> <dependencyManagement> <dependencies> <dependency> <groupId>moduleAGroupId</groupId> <artifactId>moduleAArtifactId</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> </dependencyManagement> </project pom.xml (module A) <project> <parent> <groupId>rootGroupId</groupId> <artifactId>rootArtifactId</artifactId> <version>1.0-SNAPSHOT</version> </parent> <groupId>moduleAGroupId</groupId> <artifactId>moduleAArtifactId</artifactId> </project pom.xml (module B) <project> <parent> <groupId>rootGroupId</groupId> <artifactId>rootArtifactId</artifactId> <version>1.0-SNAPSHOT</version> </parent> <groupId>moduleBGroupId</groupId> <artifactId>moduleBArtifactId</artifactId> <dependencies> <dependency> <groupId>moduleAGroupId</groupId> <artifactId>moduleAArtifactId</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> </project >> >> >> >> --------------------------------------------------------------------- >> 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]
