I can think of two options: - externalise all your versions to a properties file - create an m2 POM and use that from the Ant tasks instead. The QA team can use a copy of the POM with different dependencies and you can switch the two from a command line switch by externalising the POM filename to a property.
The latter would be preferred. Cheers, Brett On 8/27/05, Rick Mann <[EMAIL PROTECTED]> wrote: > We would like to be able to force a local build environment to > substitute a different .jar for one called for in a build.xml > <artifact:dependencies> task. > > For example, say a project has this in its build.xml file: > > <artifact:dependencies filesetId="runtime.fileset"> > <dependency groupId="log4j" artifactId="log4j" > version="1.2.1"/> > </artifact:dependencies> > > I'd like to be able to specify, outside of that build file (perhaps > in .m2/settings.xml) that any project (or better still, a specific > ant project) asking for log4j v1.2.1 (or log4j versions in some > range) should instead go get log4j v1.2.9. > > This is a requirement brought up by our QA dept. They want to test a > project (or often a collection of projects) with a new version of > some dependency. We engineers don't want to deal with a lot of > conditional glue in our build.xml files, and we want the build.xml to > be the authoritative source for dependency information in absence of > some local override. > > What do you think? > > TIA, > > -- > Rick > > > > --------------------------------------------------------------------- > 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]
