Following the properties processing rule that Joe had quoted. You will notice that everything goes through you build.properties
So if you define a version in your build.properties you can access it in your dependencies.
For example:
//build.properties
java.style.version=2.9.9
// for each project that you use jrefactory/javastyle in simply define the dependency as:
<!-- pretty task -->
<dependency>
<groupId>jrefactory</groupId>
<artifactId>JavaStyle</artifactId>
<version>${java.style.version}</version>
</dependency>
You can also define an xml file with your dependencies section and include that with each project using standard xml inclusion.
This is much less typing and very similar to how all your ant files have that line.. well now all your project.properties file with have a xml include line.
You can also create a base project.xml with all your dependencies and their correct versions and use <extend> from your subproject's in order to bring those dependencies in.
There are more options (including the @FOO_VERSION@ syntax that alot of people seem to like to use) but I've only used the ones above.
A cool feature being worked on by the maven group is the inclusion of dependencies from a POM (your project.xml is basically a POM.. when you upload your artifact to a repository it will create a poms folder with your project.xml renamed to project.pom). This will allow people to get all the dependencies of a particular project directly into their project.
Hope that helps, -Tim :)
Joe Germuska wrote:
that lets me define the individual versions of *all* dependencies for *all*
projects so that I can say, for example, use *this* version of
commons-beanutils and *that* version of commons-digester to build ***all*** of
the components that are going in to my overall exectable. I am *so* not
interested in dealing with runtime exceptions because different dependent
packages were compiled against different versions of the dependent libraries.
Can someone please help me understand how to do this with Maven? Without it,
I'm not planning to switch any of my personal or internal-to-Sun projects (even
if the Struts committers decide to switch Struts development itself).
This is actually pretty easy, if I understand you correctly. If you define the Maven property "maven.jar.override" to the value "on", then when resolving dependencies, Maven will check each against a possibly defined override.
For example, the version of Cactus that everyone else in Struts uses doesn't work on Mac OS X. The Cactus CVS head has the patch that works, so in my Struts/maven environment, I have this defined:
maven.jar.override=on # patched version of cactus related to Mac OS X: # http://issues.apache.org/bugzilla/show_bug.cgi?id=25266i maven.jar.cactus-ant=1.6dev-2003-12-07 maven.jar.jakarta-cactus-framework=13-1.6dev
You can use full paths to JARs as well as version numbers. This is detailed here:
http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
Properties are defined like so: (http://maven.apache.org/reference/user-guide.html#Properties_Processing):
The properties files in Maven are processed in the following order:
* ${project.home}/project.properties * ${project.home}/build.properties * ${user.home}/build.properties
Where the last definition wins. So, Maven moves through this sequence of properties files overridding any previously defined properties with newer definitions. In this sequence your ${user.home}/build.properties has the final say in the list of properties files processed. We will call the list of properties files that Maven processes the standard properties file set.
In addition, System properties are processed after the above chain of properties files are processed. So, a property specified on the CLI using the -Dproperty=value convention will override any previous definition of that property.
So if you wanted to have it universally, you'd define this in "${user.home}/build.properties" but if it were just for a specific project, you'd define it in ${project.home}/build.properties
Did I answer the right question?
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
