The following comment has been added to this issue:
Author: Arnaud HERITIER
Created: Fri, 14 Jan 2005 4:39 PM
Body:
Hi Dennis,
Ok, I'll add your property with by default the new behaviour. As you say, it
will allow the user to deactivate it.
I'll rename your property "maven.ant.use.properties" because in a future we
could imagine that it'll be possible to use the properties for something else.
I also don't test this property to generate the "get" command. It is always the
same with the use of an ant property. The difference is only to load or not
build.properties files.
I think also that we can add <property file="$${user.home}/build.properties"/>
as it is done in a lot of ant scripts (jakarta-commons, struts, ..). With that
a user will be able to use the same libraires for several projects.
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/MPANT-20?page=comments#action_28966
---------------------------------------------------------------------
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: Fri, 14 Jan 2005 4:39 PM
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]
