You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ben Storey <be...@gmail.com> on 2009/04/08 11:09:35 UTC
Maven 2.1 and Maven 2.0.9 changes
Hi,
We ran into a problem I thought I would make you aware of one of my
colleagues was running maven 2.1 and we were all running maven 2.0.9
When deploying with version 2.1.0 and you have properties setup like the
following in the root project.
<prroperties>
<commons-logging.version>1.1</commons-logging.version>
</properties>
…
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>${commons-logging.version} </groupId>
</dependency>
</dependencies>
</dependencyManagement>
When you do the deploy with 2.0.9 it deploys like above, however when
deploying in 2.1. it substitutes the dependencyManagement version property
like below.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</groupId>
</dependency>
</dependencies>
</dependencyManagement>
This means in the child projects we cannot override the version by the
following:
<properties>
<commons-logging.version>1.1.1<commons-logging.version>
</properties>
Because maven does not do the substitution because there is no variable to
substitute in the root descriptor.
With the way we are using maven currently the dependencyManagement elements
we want to be able to override some of our own library versions.
Is this an enhancement or a bug?
Cheers
Ben
Re: Maven 2.1 and Maven 2.0.9 changes
Posted by Ben Storey <be...@gmail.com>.
Thanks for the quick update will do that.
On Wed, Apr 8, 2009 at 10:21 AM, Brett Porter <br...@apache.org> wrote:
> This change was by design in 2.1. You should be overriding the version in
> the child by specifying the dependencyManagement section again.
>
> - Brett
>
>
> On 08/04/2009, at 7:09 PM, Ben Storey wrote:
>
> Hi,
>>
>> We ran into a problem I thought I would make you aware of one of my
>> colleagues was running maven 2.1 and we were all running maven 2.0.9
>>
>> When deploying with version 2.1.0 and you have properties setup like the
>> following in the root project.
>>
>> <prroperties>
>>
>> <commons-logging.version>1.1</commons-logging.version>
>>
>> </properties>
>>
>> …
>>
>> <dependencyManagement>
>>
>> <dependencies>
>>
>> <dependency>
>>
>> <groupId>commons-logging</groupId>
>>
>> <artifactId>commons-logging</artifactId>
>>
>> <version>${commons-logging.version} </groupId>
>>
>> </dependency>
>>
>> </dependencies>
>>
>> </dependencyManagement>
>>
>>
>>
>> When you do the deploy with 2.0.9 it deploys like above, however when
>> deploying in 2.1. it substitutes the dependencyManagement version property
>> like below.
>>
>>
>>
>> <dependencyManagement>
>>
>> <dependencies>
>>
>> <dependency>
>>
>> <groupId>commons-logging</groupId>
>>
>> <artifactId>commons-logging</artifactId>
>>
>> <version>1.1</groupId>
>>
>> </dependency>
>>
>> </dependencies>
>>
>> </dependencyManagement>
>>
>>
>>
>> This means in the child projects we cannot override the version by the
>> following:
>>
>>
>>
>> <properties>
>>
>> <commons-logging.version>1.1.1<commons-logging.version>
>>
>> </properties>
>>
>>
>> Because maven does not do the substitution because there is no variable to
>> substitute in the root descriptor.
>>
>> With the way we are using maven currently the dependencyManagement
>> elements
>> we want to be able to override some of our own library versions.
>>
>> Is this an enhancement or a bug?
>>
>> Cheers
>>
>> Ben
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Maven 2.1 and Maven 2.0.9 changes
Posted by "Nord, James" <JN...@nds.com>.
Strange - I have exactly that and I just did a test with 2.1.0 and it
worked just the same as with 2.0.9
(mvn deploy of a snapshot version)
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.nds.project</groupId>
<artifactId>runtime</artifactId>
<version>${runtimeVersion}</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
Is it the core or a plug-in that is responsible for this?
/James
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: 08 April 2009 10:21
> To: Maven Users List
> Subject: Re: Maven 2.1 and Maven 2.0.9 changes
>
> This change was by design in 2.1. You should be overriding
> the version in the child by specifying the
> dependencyManagement section again.
>
> - Brett
>
> On 08/04/2009, at 7:09 PM, Ben Storey wrote:
>
> > Hi,
> >
> > We ran into a problem I thought I would make you aware of one of my
> > colleagues was running maven 2.1 and we were all running maven 2.0.9
> >
> > When deploying with version 2.1.0 and you have properties
> setup like
> > the following in the root project.
> >
> > <prroperties>
> >
> > <commons-logging.version>1.1</commons-logging.version>
> >
> > </properties>
> >
> > ...
> >
> > <dependencyManagement>
> >
> > <dependencies>
> >
> > <dependency>
> >
> > <groupId>commons-logging</groupId>
> >
> > <artifactId>commons-logging</artifactId>
> >
> > <version>${commons-logging.version} </groupId>
> >
> > </dependency>
> >
> > </dependencies>
> >
> > </dependencyManagement>
> >
> >
> >
> > When you do the deploy with 2.0.9 it deploys like above,
> however when
> > deploying in 2.1. it substitutes the dependencyManagement version
> > property like below.
> >
> >
> >
> > <dependencyManagement>
> >
> > <dependencies>
> >
> > <dependency>
> >
> > <groupId>commons-logging</groupId>
> >
> > <artifactId>commons-logging</artifactId>
> >
> > <version>1.1</groupId>
> >
> > </dependency>
> >
> > </dependencies>
> >
> > </dependencyManagement>
> >
> >
> >
> > This means in the child projects we cannot override the
> version by the
> > following:
> >
> >
> >
> > <properties>
> >
> > <commons-logging.version>1.1.1<commons-logging.version>
> >
> > </properties>
> >
> >
> > Because maven does not do the substitution because there is no
> > variable to
> > substitute in the root descriptor.
> >
> > With the way we are using maven currently the dependencyManagement
> > elements
> > we want to be able to override some of our own library versions.
> >
> > Is this an enhancement or a bug?
> >
> > Cheers
> >
> > Ben
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
**************************************************************************************
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.
To protect the environment please do not print this e-mail unless necessary.
NDS Limited Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 2.1 and Maven 2.0.9 changes
Posted by Brett Porter <br...@apache.org>.
This change was by design in 2.1. You should be overriding the version
in the child by specifying the dependencyManagement section again.
- Brett
On 08/04/2009, at 7:09 PM, Ben Storey wrote:
> Hi,
>
> We ran into a problem I thought I would make you aware of one of my
> colleagues was running maven 2.1 and we were all running maven 2.0.9
>
> When deploying with version 2.1.0 and you have properties setup like
> the
> following in the root project.
>
> <prroperties>
>
> <commons-logging.version>1.1</commons-logging.version>
>
> </properties>
>
> …
>
> <dependencyManagement>
>
> <dependencies>
>
> <dependency>
>
> <groupId>commons-logging</groupId>
>
> <artifactId>commons-logging</artifactId>
>
> <version>${commons-logging.version} </groupId>
>
> </dependency>
>
> </dependencies>
>
> </dependencyManagement>
>
>
>
> When you do the deploy with 2.0.9 it deploys like above, however when
> deploying in 2.1. it substitutes the dependencyManagement version
> property
> like below.
>
>
>
> <dependencyManagement>
>
> <dependencies>
>
> <dependency>
>
> <groupId>commons-logging</groupId>
>
> <artifactId>commons-logging</artifactId>
>
> <version>1.1</groupId>
>
> </dependency>
>
> </dependencies>
>
> </dependencyManagement>
>
>
>
> This means in the child projects we cannot override the version by the
> following:
>
>
>
> <properties>
>
> <commons-logging.version>1.1.1<commons-logging.version>
>
> </properties>
>
>
> Because maven does not do the substitution because there is no
> variable to
> substitute in the root descriptor.
>
> With the way we are using maven currently the dependencyManagement
> elements
> we want to be able to override some of our own library versions.
>
> Is this an enhancement or a bug?
>
> Cheers
>
> Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org