Ernst de Haan wrote:
Thanks, Nicola. Interesting alternative!
So if I understand you correctly, you have version numbers on the
aggregator and on modules below that, but you just keep those to a
fixed vale (say "0") and use the root parent version to the outside
world?
No, once version numbers are specified in your parent POM's
dependencyManagement element you don't need to specify them again. To
give an example in a module POM I would specify a dependency to
bcprov-jdk13 as
<dependencies>
<dependency>
<groupId>bouncycastle</groupId>
<artifactId>bcprov-jdk13</artifactId>
</dependency>
</dependencies>
Cheers,
Nicola
Cheers,
Ernst de Haan
Op 25 mei 2010 om 14:28 heeft Nicola Musatti
<[email protected]> het volgende geschreven:\
I keep all version numbers in the dependencyManagement section of my
parent POM, which is different from my aggregator POM and is parent
to the aggregator and all its modules. In this way I specify each
version exactly once. Something like:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>bouncycastle</groupId>
<artifactId>bcprov-jdk13</artifactId>
<version>140</version>
</dependency>
</dependencyManagement>
dependencyManagement is a direct child of the project element.
Cheers,
Nicola Musatti
Ernst de Haan wrote:
- in the parent pom.xml, to denote the project version
you need this
- in each module, to denote the module version
just leave out the version and it will inherit it from the parent pom
- in each module's reference to the parent
you need this
- in each module's reference to a sibling
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>sibling-one</artifactId>
<version>${project.parent.version}</version>
</dependency>
Thanks a lot Kristian, this indeed improves the situation a *lot*.
Instead of 10 references for 3 modules, I am now able to reduce it to:
1 + (1 per module)
However, I'll continue my quest to further reduction of replication,
as my ultimate goal is still to have the version number in one
place. Perhaps XInclude or so will do the trick.
Thanks heaps!
Ernst
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
