The following comment has been added to this issue:
Author: Dennis Lundberg
Created: Fri, 14 Jan 2005 2:20 PM
Body:
Hi Arnaud
I think that it is very *unlikely* that someone will run into problems with
clashing properties.
We could invert the configuration property so that it defaults to true. That
way if someone do run into problems with clashing properties they could set the
config property to false to get back the behaviour of the ant-plugin v 1.8.1.
It all depends on what the users say. But if you ask me we might as well skip
the config property (like you have done).
Regarding the names of the properties in the generated build.xml file I I have
thought about it some more now, and I realize that my first choice of
property-names was wrong. I imagined that one would have one build.properties
file for *all* projects, but since the build.properties file will be in the
directory of *one* project, it make sense not to include the version number in
the property name.
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/MPANT-20?page=comments#action_28964
---------------------------------------------------------------------
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 2:20 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]
