Damn, I just bumped in to this problem only to find that there is still no solution. I am trying to do a very similar thing. When one of my libraries depends on hibernate, for example, I am using properties in the deployed pom file to specify which version should be used by default if a person where to use my jar file in their project. However, if they don't want that version of hibernate, they theoretically would set the same property in their own pom.xml file. Only, just as Matt has pointed out, the dependency pom is taking precedence over the user's pom.xml. This behavior makes absolutely no sense, especially since it is possible to achieve this override from the commandline. The perfectly logical order would be: dependency pom -> user pom -> commandline flag.
Dan Allen added a comment - 13/Jun/07 08:37 PM Damn, I just bumped in to this problem only to find that there is still no solution. I am trying to do a very similar thing. When one of my libraries depends on hibernate, for example, I am using properties in the deployed pom file to specify which version should be used by default if a person where to use my jar file in their project. However, if they don't want that version of hibernate, they theoretically would set the same property in their own pom.xml file. Only, just as Matt has pointed out, the dependency pom is taking precedence over the user's pom.xml. This behavior makes absolutely no sense, especially since it is possible to achieve this override from the commandline. The perfectly logical order would be: dependency pom -> user pom -> commandline flag.
Here is some XML to demonstrate what I am doing:
some-cool-library.pom
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernate.version}</version>
</dependency>
<properties>
<hibernate.version>3.2.1.ga</hibernate.version>
</properties>
user's pom.xml
<properties>
<hibernate.version>3.2.4.sp1</hibernate.version>
</properties>
result: no dice.
this can now be corrected by using the dependency management element for hibernate in your own POM rather than taking a stab at the properties they might have used.
Brett Porter added a comment - 18/Dec/08 08:19 AM this can now be corrected by using the dependency management element for hibernate in your own POM rather than taking a stab at the properties they might have used.
Wish
Closed
Major
Allow dependency properties to be overriden by projects that use them
Here is some XML to demonstrate what I am doing:
some-cool-library.pom
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernate.version}</version>
</dependency>
<properties>
<hibernate.version>3.2.1.ga</hibernate.version>
</properties>
user's pom.xml
<properties>
<hibernate.version>3.2.4.sp1</hibernate.version>
</properties>
result: no dice.