Yes I tried that, but that only seems to work on jar's, not war's, and that
only helps with my ear:
<dependency>
<groupId>com.furl.common</groupId>
<artifactId>common-jar</artifactId>
<version>${common.version}</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>com.furl</groupId>
<artifactId>core</artifactId>
<version>${core.version}</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>com.furl.furl-web</groupId>
<artifactId>looksmart</artifactId>
<version>${looksmart.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>com.furl.furl-web</groupId>
<artifactId>nytimes</artifactId>
<version>${nyt.version}</version>
<type>war</type>
</dependency>
is in my master pom (${...} comes from my profiles.xml right now), but this
still did not address my common-jar's parent. I still had to hard code that
in the common-jar pom.xml
---
Thank You
Mick Knutson
Sr. Java/J2EE Consultant
BASE logic, inc.
(415) 648-1804 (S.F., CA)
http://www.BASELogic.com
Washington Mutual (WAMU) (Emeryville, California)
---
From: "mvdp" <[EMAIL PROTECTED]>
Reply-To: "Maven Users List" <[email protected]>
To: "Maven Users List" <[email protected]>
Subject: RE: [m202] Still confused as to a solution to complex versioning
Date: Fri, 24 Feb 2006 09:03:27 +0100
Hi Mick,
Have you investigated the use of the dependencyManagement section in the
project model docs
in http://maven.apache.org/maven-model/maven.html
I use dependencyManagement in our master pom as a central point for version
specification.
All other poms have the master pom as parent. The child poms define
dependencies without the version element.
This way you also don't need to define properties.
Hope this helps.
Martin
-----Oorspronkelijk bericht-----
Van: Mick Knutson [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 24 februari 2006 0:11
Aan: [email protected]
Onderwerp: [m202] Still confused as to a solution to complex versioning
I started creating a profile for my build like:
<profile>
<id>1.3.5_6</id>
<properties>
<coreVersion>1.1.4_4</coreVersion>
<commonVersion>1.0_1</commonVersion>
<lksmWarVersion>1.3.5_6</lksmWarVersion>
<nytWarVersion>1.2.2_1</nytWarVersion>
<earVersion>1.3.5_6</earVersion>
</properties>
</profile>
I have a master pom and ear that share the same version number (1.3.5_6)
and
then 5 modules that have different versions from that.
We need the ability to deploy the following:
1.3.5_6.ear contains: core-1.1.4_4, common-1.0_1, lksm-1.3.5_6.war, and
nyt-1.2.2_1.war
then rollback the core version and deploy:
1.3.5_7.ear contains: core-1.1.4_3, common-1.0_2, lksm-1.3.5_7.war, and
nyt-1.2.2_2.war
then include the latest of everything:
1.3.5_8.ear contains: core-1.1.4_5, common-1.0_3, lksm-1.3.5_7.war, and
nyt-1.2.2_2.war
But with this, there is the issue of keeping the version numbers updated in
8 different pom's.
There must be some way to help me centralize this. Help?
---
Thank You
Mick Knutson
Sr. Java/J2EE Consultant
BASE logic, inc.
(415) 648-1804 (S.F., CA)
http://www.BASELogic.com
Washington Mutual (WAMU) (Emeryville, California)
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.0.0/268 - Release Date: 23-02-2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.0.0/268 - Release Date: 23-02-2006
---------------------------------------------------------------------
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]
