On Jul 14, 2010, at 8:32 PM, Rex Wang wrote:

2010/7/15 David Jencks <david_jencks@yahoo.com>

On Jul 13, 2010, at 7:56 PM, Rex Wang wrote:


I suggest we stop using ${project.version} in 3.0's pom.
This maven variable will magicly change when I create a new sub-project which has it own version.
For example,
When I create a new server assembly "abc" under the assemblies project, and the abc's pom has it own version

Then, in its effective pom, maven will replace all the ${project.version} defined in parent pom with

I think we use ${geronimoVersion} instead and specify geronimoVersion explicitly in root pom.


I think this is a really bad idea.  In your example above, you should not have the explicit version <version></version>

Generally, if you want a different version for a particular project, put the project in a different tree without a file system parent pom.  
It will save a lot of time to create a custom assembly with geronimo's parent pom..and if all the sub-poms can not have its version and must use {project.version}, which is actually the geronimo root pom's version. What's the difference/risk between using a geronimoVersion property and that? Actually, geronimoVersion has already been used in 3.0-m1 & trunk...

Months later.....  I think I understand the circumstances you are talking about.

I agree with you that this is a big problem.  Hardcoding the version will also work since the release plugin is good at updating it everywhere necessary.    I guess using the property will be slightly more convenient.

david jencks

There are a few special cases like the bundles.... even those probably shouldn't have a file system parent pom (not actually sure if they do right now).

david jencks

Lei Wang (Rex)
rwonly AT apache.org

Lei Wang (Rex)
rwonly AT apache.org