Currently with the modular build, there is no easy way to load global properties such that they are available for use inside of project.xml. If this was the case we could use properties to handle dependency versioning. If project.xml was a Jelly script (as the Maven user-guide suggests it is), then we could use Jelly to handle including dependency information, which IMO is the best option... but short-term until Maven has better support we should implement something which does not require a modification to Maven code.
James and I have talked about this some, and have came up with some ideas. Some which require modifications to Maven have been communicated back to the Maven Users list, but I do not know how soon or even if those changes will make it in to Maven any time soon.
James suggested creating a meta module which had all of the dependencies for the entire project and then as a default target would re-install those dependencies with a special version token (similar to SNAPSHOT). Basically if a module depends on mx4j-jmx-SNAPSHOT.jar, this meta module would depend on:
<dependency>
<groupId>mx4j</groupId>
<artifactId>mx4j-jmx</artifactId>
<version>SNAPSHOT</version>
<url>http://mx4j.sourceforge.net</url>
</dependency>And such it would check for a newer version when executed. The meta module would then re-install the dependency with a version like CURRENT, possibly into a seperate group, like geronimo-dependency, to keep the hack localized to Geronimo until Maven can handle this problem nativly.
A regular module which depens on mx4j-jmx would depend on:
<dependency>
<groupId>geronimo-dependency</groupId>
<artifactId>mx4j-jmx</artifactId>
<version>CURRENT</version>
</dependency>I like this idea as a short-term solution because it will fit our needs and it will also speed things up a tad as modules which depend on a SNAPSHOT will not attempt to download a new artifact which may have already been checked for a newer version by a previous module.
The downside is that the dependency meta module will need to be depended upon by all other modules and it will have to be executed before modules will function outside of the reactor. I do not think this is a big deal as there are already such problems when trying to perform a clean build when dependencies have not been fully resolved.
Comments? Suggestions?
--jason
