You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2007/05/06 17:30:45 UTC

Version number propogation

I have a project with multiple modules.

I'm keeping the version numbers synced.

This ends up with a lot of repetition of the version number:

  <artifactId>tapestry-core</artifactId>
  <packaging>jar</packaging>
  <version>5.0.5-SNAPSHOT</version>
  <parent>
    <groupId>org.apache.tapestry</groupId>
    <artifactId>tapestry-project</artifactId>
    <version>5.0.5-SNAPSHOT</version>
    <relativePath>../tapestry-project/pom.xml</relativePath>
  </parent>


Worse yet, those same version numbers are creeping into documentation and
into project archetypes.

How would I go about externalizing the version number so that it appears
just once?  I'd love to have something like I used to do in Ant ... a
build.properties file that defines the version number.

Also, is there a general way to include POM properties inside APT documents
and/or site.xml?

-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

Re: Version number propogation

Posted by Wayne Fay <wa...@gmail.com>.
The relative path doesn't necessarily work once deployed. And its not
guaranteed to be true -- you could checkout just the module rather
than the entire project, and suddenly Maven can't find that parent
since the relativePath is no longer accurate.

If anything, I'd argue that relativePath should perhaps be removed.

Wayne

On 5/7/07, David Corbin <dc...@allureglobal.com> wrote:
> On Sunday 06 May 2007 19:20, Bryan Loofbourrow wrote:
> > I believe that you are correct about not being able to parameterize the
> > project parent tag, or so a co-worker tells me. He conjectures that the
> > parent resolution is required before resolution of property names. That
> > makes sense, since, in general, the value you're looking for could be
> > defined in the parent pom,
>
> But when I provide a <relativePath> tag in parent declaration, that should
> allow be enough.  In fact, if I provide r<relativePath> all the artifact
> information provided should just be a safety check.
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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


Re: Version number propogation

Posted by David Corbin <dc...@allureglobal.com>.
On Sunday 06 May 2007 19:20, Bryan Loofbourrow wrote:
> I believe that you are correct about not being able to parameterize the
> project parent tag, or so a co-worker tells me. He conjectures that the
> parent resolution is required before resolution of property names. That
> makes sense, since, in general, the value you're looking for could be
> defined in the parent pom, 

But when I provide a <relativePath> tag in parent declaration, that should 
allow be enough.  In fact, if I provide r<relativePath> all the artifact 
information provided should just be a safety check.

David

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


RE: Version number propogation

Posted by Bryan Loofbourrow <br...@islandbeast.com>.
I believe that you are correct about not being able to parameterize the
project parent tag, or so a co-worker tells me. He conjectures that the
parent resolution is required before resolution of property names. That
makes sense, since, in general, the value you're looking for could be
defined in the parent pom, but it does create a situation in which it
doesn't seem possible to have your consistent version number for a
multimodule project in a single place. I suspect that the official answer is
that you're the only place you're supposed to impose a single version number
on a multimodule project is via the release plugin, which copies the same
version number into everything you're releasing. It does seem as though
parameterzing parent version tags within a multimodule project might
interfere with the release plugin, or vice versa, even if it were allowed.

-- Bryan

-----Original Message-----
From: Martin Gilday [mailto:martin.lists@imap.cc] 
Sent: Sunday, May 06, 2007 12:50 PM
To: Maven Users List
Subject: Re: Version number propogation

You can use ${pom.version} in some circumstances.  I think a parent tag
might be a case where you can't though.


----- Original message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Maven Users List" <us...@maven.apache.org>
Date: Sun, 6 May 2007 08:30:45 -0700
Subject: Version number propogation

I have a project with multiple modules.

I'm keeping the version numbers synced.

This ends up with a lot of repetition of the version number:

  <artifactId>tapestry-core</artifactId>
  <packaging>jar</packaging>
  <version>5.0.5-SNAPSHOT</version>
  <parent>
    <groupId>org.apache.tapestry</groupId>
    <artifactId>tapestry-project</artifactId>
    <version>5.0.5-SNAPSHOT</version>
    <relativePath>../tapestry-project/pom.xml</relativePath>
  </parent>


Worse yet, those same version numbers are creeping into documentation
and
into project archetypes.

How would I go about externalizing the version number so that it appears
just once?  I'd love to have something like I used to do in Ant ... a
build.properties file that defines the version number.

Also, is there a general way to include POM properties inside APT
documents
and/or site.xml?

-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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


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


Re: Version number propogation

Posted by Kalle Korhonen <ka...@gmail.com>.
You can also declare your own properties in a properties section, for
example:
<properties>
   <log4j.version>1.2.14</log4j.version>
</properties>

That you can then refer to with ${log4j.version} anywhere in your poms,
including the child poms. But there's no way to include a properties file
and read the information from there.

Kalle

PS. Note it's usually better to use dependencyManagement for version info,
but the above happens to be a live example for sharing version between
plugin- and dependencyManagement sections.

On 5/6/07, Martin Gilday <ma...@imap.cc> wrote:
>
> You can use ${pom.version} in some circumstances.  I think a parent tag
> might be a case where you can't though.
>
>
> ----- Original message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Maven Users List" <us...@maven.apache.org>
> Date: Sun, 6 May 2007 08:30:45 -0700
> Subject: Version number propogation
>
> I have a project with multiple modules.
>
> I'm keeping the version numbers synced.
>
> This ends up with a lot of repetition of the version number:
>
>   <artifactId>tapestry-core</artifactId>
>   <packaging>jar</packaging>
>   <version>5.0.5-SNAPSHOT</version>
>   <parent>
>     <groupId>org.apache.tapestry</groupId>
>     <artifactId>tapestry-project</artifactId>
>     <version>5.0.5-SNAPSHOT</version>
>     <relativePath>../tapestry-project/pom.xml</relativePath>
>   </parent>
>
>
> Worse yet, those same version numbers are creeping into documentation
> and
> into project archetypes.
>
> How would I go about externalizing the version number so that it appears
> just once?  I'd love to have something like I used to do in Ant ... a
> build.properties file that defines the version number.
>
> Also, is there a general way to include POM properties inside APT
> documents
> and/or site.xml?
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Version number propogation

Posted by Martin Gilday <ma...@imap.cc>.
You can use ${pom.version} in some circumstances.  I think a parent tag
might be a case where you can't though.


----- Original message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Maven Users List" <us...@maven.apache.org>
Date: Sun, 6 May 2007 08:30:45 -0700
Subject: Version number propogation

I have a project with multiple modules.

I'm keeping the version numbers synced.

This ends up with a lot of repetition of the version number:

  <artifactId>tapestry-core</artifactId>
  <packaging>jar</packaging>
  <version>5.0.5-SNAPSHOT</version>
  <parent>
    <groupId>org.apache.tapestry</groupId>
    <artifactId>tapestry-project</artifactId>
    <version>5.0.5-SNAPSHOT</version>
    <relativePath>../tapestry-project/pom.xml</relativePath>
  </parent>


Worse yet, those same version numbers are creeping into documentation
and
into project archetypes.

How would I go about externalizing the version number so that it appears
just once?  I'd love to have something like I used to do in Ant ... a
build.properties file that defines the version number.

Also, is there a general way to include POM properties inside APT
documents
and/or site.xml?

-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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


Re: Version number propogation

Posted by Wendy Smoak <ws...@gmail.com>.
On 5/6/07, Howard Lewis Ship <hl...@gmail.com> wrote:

> I have a project with multiple modules.
>
> I'm keeping the version numbers synced.
>
> This ends up with a lot of repetition of the version number:
>
>   <artifactId>tapestry-core</artifactId>
>   <packaging>jar</packaging>
>   <version>5.0.5-SNAPSHOT</version>
>   <parent>
>     <groupId>org.apache.tapestry</groupId>
>     <artifactId>tapestry-project</artifactId>
>     <version>5.0.5-SNAPSHOT</version>
>     <relativePath>../tapestry-project/pom.xml</relativePath>
>   </parent>

You can use ${project.version} in the poms.

> Worse yet, those same version numbers are creeping into documentation and
> into project archetypes.

I think you will still need to tie the archetype to a particular
version of your project.  What's the issue with documentation?

> How would I go about externalizing the version number so that it appears
> just once?  I'd love to have something like I used to do in Ant ... a
> build.properties file that defines the version number.
>
> Also, is there a general way to include POM properties inside APT documents
> and/or site.xml?

The next version of the site plugin will do this, check the dev list
for more info.  Right now it's too aggressive and filters everything,
which breaks existing sites that wanted the literal expression to be
displayed.  Jason is going to change it so it only filters things in a
certain directory.

-- 
Wendy

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


Re: Version number propogation

Posted by Wendy Smoak <ws...@gmail.com>.
On 5/6/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> I have a project with multiple modules.
>
> I'm keeping the version numbers synced.
>
> This ends up with a lot of repetition of the version number:
>
>   <artifactId>tapestry-core</artifactId>
>   <packaging>jar</packaging>
>   <version>5.0.5-SNAPSHOT</version>
>   <parent>
>     <groupId>org.apache.tapestry</groupId>
>     <artifactId>tapestry-project</artifactId>
>     <version>5.0.5-SNAPSHOT</version>
>     <relativePath>../tapestry-project/pom.xml</relativePath>
>   </parent>

Looking at this again after reading Bryan's response... yes, you will
have to specify the version for the parent in every child pom.  (In
the example above, I think the first <version> element is redundant as
it will get inherited from the parent.)

${project.version} is useful when there are dependencies between child
modules, such as if a webapp depends on a jar within the same
multi-module build.

And yes, the release plugin will take care of changing all of these
version elements to the released version for the tag, and then to the
next snapshot version.

-- 
Wendy

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


Re: Version number propogation

Posted by Roland Asmann <Ro...@cfc.at>.
On Sunday 06 May 2007 17:30, Howard Lewis Ship wrote:
> I have a project with multiple modules.
>
> I'm keeping the version numbers synced.
>
> This ends up with a lot of repetition of the version number:
>
>   <artifactId>tapestry-core</artifactId>
>   <packaging>jar</packaging>
>   <version>5.0.5-SNAPSHOT</version>
>   <parent>
>     <groupId>org.apache.tapestry</groupId>
>     <artifactId>tapestry-project</artifactId>
>     <version>5.0.5-SNAPSHOT</version>
>     <relativePath>../tapestry-project/pom.xml</relativePath>
>   </parent>
>
>
> Worse yet, those same version numbers are creeping into documentation and
> into project archetypes.
>
> How would I go about externalizing the version number so that it appears
> just once?  I'd love to have something like I used to do in Ant ... a
> build.properties file that defines the version number.
>
> Also, is there a general way to include POM properties inside APT documents
> and/or site.xml?

What we do here, is define a parent-POM which holds the version-number. All 
child-projects to this POM, must at least define the version for the 
parent-project, but from there on, you don't need to define them anymore.

Example:
<project>
	<parent>
		<groupId>my.group</groupId>
		<artifactId>parent-artifact</artifactId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<artifactId>artifact</artifactId>
	<dependencies>
		<dependency>
			<groupId>${groupId}</groupId>
			<artifactId>another-artifact</artifactId>
			<version>${project.version}</version>
		</dependency>
	</dependencies>
</project>

This project references the parent over a version, inherits that version as 
its own version and even uses it to reference another child-project as a 
dependency (with that same version again).

Now, if you were to use the release-plugin, you'd never have to change 
anything here (unless you explicitly want to use another version of a 
parent/dependency).

-- 
Roland Asmann

CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien

Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: Roland.Asmann@cfc.at
Web: www.cfc.at

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