Affects Version/s: None
Fix Version/s: 1.9
Number of attachments :
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).