You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Sven Vlieghe <sv...@gmail.com> on 2008/08/26 15:31:56 UTC

Resolving dependency properties

Hi there,

I am trying to centralize the version-numbers of all projects/dependencies
in our system. My approach for this, is to centralize the settings.xml-file
& add all versions as profile-properties. This worked perfectly at first
sight, but resulted in errors when trying to use the project as a
dependency.


Example settings.xml:
<settings>
...
	<profiles>
		<profile>
			<id>my-active-profile</id>
			<properties>
				<version.test>2.2.0</version.test>
			</properties>
		</profile>
	</profiles>
	<activeProfiles>
		<activeProfile>my-active-profile</activeProfile>
	</activeProfiles>
</settings>


Example project pom.xml:
<project>
	<artifactId>some-project</artifactId>
...
	<dependencies>
		<!-- project dependencies -->
		<dependency>
			<groupId>my.group.id</groupId>
			<artifactId>test-program</artifactId>
			<version>${version.test}</version>
		</dependency>
	</dependencies>
</project>


When trying to build 'some-project', maven is capable of resolving
${version.test} into the correct version. No problems here.


However, when adding 'some-project' as a dependency of an other project:
<project>
	<artifactId>some-other-project</artifactId>
...
	<dependencies>
		<!-- project dependencies -->
		<dependency>
			<groupId>my.group.id</groupId>
			<artifactId>some-project</artifactId>
		</dependency>
	</dependencies>
</project>

This build fails.. maven doesn't resolve the properties in 'some-project'
(in this case, version.test) & therefore tries to find
my.group.id:test-program:${version.test} instead of
my.group.id:test-program:2.2.0


Anyone sees what I'm doing wrong?

thanks in advance,

Sven
-- 
View this message in context: http://www.nabble.com/Resolving-dependency-properties-tp19162134p19162134.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Resolving dependency properties

Posted by David Roussel <na...@diroussel.xsmail.com>.
Sven,

I did some thing like you are describing.  We used one version number for 30
or so modules.   We ran maven like this:

  mvn install -DbuildVersion=1.1-DEVELOPERNAME-SNAPSHOT

Then in the poms...

    <dependency>
        <groupId>my.group.id</groupId>
        <artifactId>test-program</artifactId>
        <version>${buildVersion}</version>
    </dependency> 

We had to hard code the parent version, couldn't get it to work with a
variable, but everything else worked fine.

David



Sven Vlieghe wrote:
> 
> Hi there,
> 
> I am trying to centralize the version-numbers of all projects/dependencies
> in our system. My approach for this, is to centralize the
> settings.xml-file & add all versions as profile-properties. This worked
> perfectly at first sight, but resulted in errors when trying to use the
> project as a dependency.
> 
> 
> Example settings.xml:
> <settings>
> ...
> 	<profiles>
> 		<profile>
> 			<id>my-active-profile</id>
> 			<properties>
> 				<version.test>2.2.0</version.test>
> 			</properties>
> 		</profile>
> 	</profiles>
> 	<activeProfiles>
> 		<activeProfile>my-active-profile</activeProfile>
> 	</activeProfiles>
> </settings>
> 
> 
> Example project pom.xml:
> <project>
> 	<artifactId>some-project</artifactId>
> ...
> 	<dependencies>
> 		<!-- project dependencies -->
> 		<dependency>
> 			<groupId>my.group.id</groupId>
> 			<artifactId>test-program</artifactId>
> 			<version>${version.test}</version>
> 		</dependency>
> 	</dependencies>
> </project>
> 
> 
> When trying to build 'some-project', maven is capable of resolving
> ${version.test} into the correct version. No problems here.
> 
> 
> However, when adding 'some-project' as a dependency of an other project:
> <project>
> 	<artifactId>some-other-project</artifactId>
> ...
> 	<dependencies>
> 		<!-- project dependencies -->
> 		<dependency>
> 			<groupId>my.group.id</groupId>
> 			<artifactId>some-project</artifactId>
> 		</dependency>
> 	</dependencies>
> </project>
> 
> This build fails.. maven doesn't resolve the properties in 'some-project'
> (in this case, version.test) & therefore tries to find
> my.group.id:test-program:${version.test} instead of
> my.group.id:test-program:2.2.0
> 
> 
> Anyone sees what I'm doing wrong?
> 
> thanks in advance,
> 
> Sven
> 

-- 
View this message in context: http://www.nabble.com/Resolving-dependency-properties-tp19162134p19180112.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Resolving dependency properties

Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Aug 27, 2008 at 12:24 AM, Sven Vlieghe <sv...@gmail.com> wrote:

> That I could, however we have this policy that we cannot have snapshot
> dependencies on released projects. I'll verify if this is the same for
> snapshot parents. If so, the snapshot parent will be the way to go.

You'll need to release the parent pom before you can release the project.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Resolving dependency properties

Posted by Sven Vlieghe <sv...@gmail.com>.

Geoffrey Wiseman wrote:
> 
> On Tue, Aug 26, 2008 at 10:30 AM, Sven Vlieghe
> <sv...@gmail.com>wrote:
> 
>> I agree, that was a setup I was originally planning to do. However, each
>> time a dependency-version increases, this would result in having to
>> increase
>> the base-pom too. That pom would have to be released to a final version,
>> and
>> all existing projects would have to update their reference to it.
>>
> 
> You could use an in-flux snapshot parent pom for that, I imagine.
> 
> -- 
> Geoffrey Wiseman
> 
> 

That I could, however we have this policy that we cannot have snapshot
dependencies on released projects. I'll verify if this is the same for
snapshot parents. If so, the snapshot parent will be the way to go.

In the meanwhile, if anyone knows a fix for that settings-issue, you're more
than welcome!

Sven Vlieghe



-- 
View this message in context: http://www.nabble.com/Resolving-dependency-properties-tp19162134p19175944.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Resolving dependency properties

Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Tue, Aug 26, 2008 at 10:30 AM, Sven Vlieghe <sv...@gmail.com>wrote:

> I agree, that was a setup I was originally planning to do. However, each
> time a dependency-version increases, this would result in having to
> increase
> the base-pom too. That pom would have to be released to a final version,
> and
> all existing projects would have to update their reference to it.
>

You could use an in-flux snapshot parent pom for that, I imagine.

-- 
Geoffrey Wiseman

Re: Resolving dependency properties

Posted by Sven Vlieghe <sv...@gmail.com>.


Wendy Smoak-3 wrote:
> 
> On Tue, Aug 26, 2008 at 6:31 AM, Sven Vlieghe <sv...@gmail.com>
> wrote:
> 
>> I am trying to centralize the version-numbers of all
>> projects/dependencies
>> in our system. My approach for this, is to centralize the
>> settings.xml-file
>> & add all versions as profile-properties. This worked perfectly at first
>> sight, but resulted in errors when trying to use the project as a
>> dependency.
> ...
>> Anyone sees what I'm doing wrong?
> 
> The settings.xml file is intended for developer-specific
> configuration... the version number of a project definitely belongs in
> the pom.
> 
> You can establish an organization-level pom that all your projects
> inherit from and specify things that are truly common across all your
> projects there, then come down to project-level parent poms for things
> that are project-specific, etc.
> 
> -- 
> Wendy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 
I agree, that was a setup I was originally planning to do. However, each
time a dependency-version increases, this would result in having to increase
the base-pom too. That pom would have to be released to a final version, and
all existing projects would have to update their reference to it.

Sven
-- 
View this message in context: http://www.nabble.com/Resolving-dependency-properties-tp19162134p19163185.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Resolving dependency properties

Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, Aug 26, 2008 at 6:31 AM, Sven Vlieghe <sv...@gmail.com> wrote:

> I am trying to centralize the version-numbers of all projects/dependencies
> in our system. My approach for this, is to centralize the settings.xml-file
> & add all versions as profile-properties. This worked perfectly at first
> sight, but resulted in errors when trying to use the project as a
> dependency.
...
> Anyone sees what I'm doing wrong?

The settings.xml file is intended for developer-specific
configuration... the version number of a project definitely belongs in
the pom.

You can establish an organization-level pom that all your projects
inherit from and specify things that are truly common across all your
projects there, then come down to project-level parent poms for things
that are project-specific, etc.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org