Message: A new issue has been created in JIRA.
--------------------------------------------------------------------- View the issue: http://jira.codehaus.org/browse/MPANT-20 Here is an overview of the issue: --------------------------------------------------------------------- Key: MPANT-20 Summary: Allow URL substitutions in generated build.xml files Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ant-plugin Assignee: Arnaud HERITIER Reporter: Craig McClanahan Created: Wed, 1 Dec 2004 1:34 AM Updated: Wed, 1 Dec 2004 1:34 AM Environment: Java Description: Issue MPANT-7 contemplates improvements to the generated build.xml file that is produced by this plugin, but it does not deal with a use case that I am facing. In various Jakarta Commons packages that I participate in, we like to cater to users who like Ant as well as those who like Maven as their build tool. To accomodate the Ant users, we have a developer periodically generate the build.xml file (using this plugin) and check it in to our CVS repository. For the most part, this approach is functional -- although I'll quibble about the fact that "ant clean dist" cleans out the downloaded dependencies, so my nightly builds of Commons packages always have to download them again, but that's a different issue :-). However, this situation fails with dependencies that cannot be publicly posted on a Maven repository. In particular, this currently affects Commons Email (which needs JavaMail and JAF jars) and Commons Chain (which needs JavaServer Faces API jars), which cannot be posted in a repository due to license restrictions. The changes for MPANT-7 seem to help if the same person is both generating the build.xml file and executing it (with overrides in your local project properties). But it doesn't help when someone *else* is going to download and execute the build.xml file. I suggest changes to the generated build.xml file along the following lines: * Add a '<property file="build.properties"/>' element at the top of the generated script, to pick up local property overrides. * For each dependency where you are going to generate a <get> command, create an Ant property that defines the default URL from which to retrieve that dependency. * In the actual <get> tasks, use the Ant property instead of a hard coded URL based on the default repository. In this way, I can point at any particular repository -- or, for that matter, to any local file if I create a file: URL -- for any given dependency. This allows users of the generated build.xml file to point at their own copies of non-redistributable JAR files, without impacting the generated build.xml file itself (which is obviously preferable to hand editing the generated file each time it is recreated). --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]