Re: Version number propogation
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 <[EMAIL PROTECTED]> 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 tag in parent declaration, that should allow be enough. In fact, if I provide r all the artifact information provided should just be a safety check. David - 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]
Re: Version number propogation
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 tag in parent declaration, that should allow be enough. In fact, if I provide r all the artifact information provided should just be a safety check. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number propogation
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:
>
> tapestry-core
> jar
> 5.0.5-SNAPSHOT
>
> org.apache.tapestry
> tapestry-project
> 5.0.5-SNAPSHOT
> ../tapestry-project/pom.xml
>
>
>
> 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:
my.group
parent-artifact
0.0.1-SNAPSHOT
artifact
${groupId}
another-artifact
${project.version}
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: [EMAIL PROTECTED]
Web: www.cfc.at
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number propogation
On 5/6/07, Howard Lewis Ship <[EMAIL PROTECTED]> 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:
tapestry-core
jar
5.0.5-SNAPSHOT
org.apache.tapestry
tapestry-project
5.0.5-SNAPSHOT
../tapestry-project/pom.xml
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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version number propogation
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:[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: "Maven Users List"
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:
tapestry-core
jar
5.0.5-SNAPSHOT
org.apache.tapestry
tapestry-project
5.0.5-SNAPSHOT
../tapestry-project/pom.xml
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number propogation
You can also declare your own properties in a properties section, for
example:
1.2.14
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
To: "Maven Users List"
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:
tapestry-core
jar
5.0.5-SNAPSHOT
org.apache.tapestry
tapestry-project
5.0.5-SNAPSHOT
../tapestry-project/pom.xml
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version number propogation
On 5/6/07, Howard Lewis Ship <[EMAIL PROTECTED]> 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:
tapestry-core
jar
5.0.5-SNAPSHOT
org.apache.tapestry
tapestry-project
5.0.5-SNAPSHOT
../tapestry-project/pom.xml
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: "Maven Users List"
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:
tapestry-core
jar
5.0.5-SNAPSHOT
org.apache.tapestry
tapestry-project
5.0.5-SNAPSHOT
../tapestry-project/pom.xml
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
