I have 2 issues:
1. If I am working on a project that has an archive with all the same
version of each artifact, then I agree I would prefer to leave the version
off and have it inherit. BUT. When I tell each archive what the parent is, I
am forced to add a parent version, thus I have to modify each and every
child pom to do this. Change that requirement, or help me to filter this.
2. When I am working on a project like now that I have core with 1 version,
then 2 different war's, each with different version numbers (for branching),
then I wanted a way to specify what version each item is, without lettting
the coders alter the pom's at all. Possible?
---
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: John Casey <[EMAIL PROTECTED]>
Reply-To: "Maven Users List" <users@maven.apache.org>
To: Maven Users List <users@maven.apache.org>
Subject: Re: [m202] can I use filters to externalize my artifact version
number?
Date: Thu, 16 Feb 2006 10:18:38 -0500
Maybe I'm missing something, but why not simply leave off the child-POM
version element? It will inherit the one specified in the parent section.
If the parent POM doesn't exist in the repository, you could always use the
<relativePath/> element in the parent section to specify where the parent
POM is relative to the current project's ${basedir}.
However, I would only recommend this for hierarchies that are meant to be
built as a single application. Once you cross that boundary to more general
information, the release cycles are different and therefore so is the
versioning. Something to remember is that Maven allows n-level inheritance.
So, if you have common information for multiple apps, and still want a
single version for the application, you can use a root POM that carries the
common information, and an application-level parent POM that inherits from
the root. This parent would be the parent of all POMs within the
application build, and would specify the version.
I know some of this is clunky, and it's in the queue for revision in Maven
2.1.
Anyway, hope that didn't muddy the waters too much.
-john
Grothaus, Christoph wrote:
Bad idea.
At least in the <parent> tags of your submodules you have to explicitly
define the parent version number. If you do a reactor build, everything is
fine without that. If you want to build a submodule standalone, Maven will
ask the repository for the parent pom. Without version number, that will
fail. And as Maven fails to resolve the parent pom, how can there be
inheritance?
As to resource filtering, that's AFAIK meant for Java resources, and not
for the POMs themselves.
Suggestion for your version number problem: put markers after all
<version>someversion</version> sequences that belong to your current
project and its submodules, like that: <version>1.0-SNAPSHOT</version><!--
myprojectversionmarker -->. Apply a strategy where all submodules have the
same version number as the master pom (e.g. by simply omitting the version
number for the child module, it will inherit its parent version number).
Too many different versions along the submodules are confusing. Now if
you have to change the version, do a search and replace on all your POMs.
It will be safe, as you have the version markers.
Just my two cents.
Christoph
-----Original Message-----
From: Allan Ramirez [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 3:18 AM
To: Maven Users List
Subject: Re: [m202] can I use filters to externalize my artifact version
number?
Hi there,
I think <properties> from the parent pom can be inherited by the sub
modules. You may want to use that
or
http://maven.apache.org/guides/getting-started/index.html#How%
20do%20I%20filter%20resource%20files?
-allan
Mick Knutson wrote:
I want an easier way to manage version numbers than having my team modify
the pom.xml. I want to keep them from touching it all together. So can I
use some soert of filtering mechanism to change:
<version>1.2.3.2</version>
to this:
<version>${core.version.number}</version>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
