The following comment has been added to this issue:
Author: Arnaud HERITIER
Created: Thu, 13 Jan 2005 7:01 PM
Body:
Dennis, I'll wait for users' comments.
Actually I applied your patch but :
- I didn't integrated the property to switch between the 2 implementations.
- I renamed properties used to override the url ${artifactId}.jar as it was
defined in struts, jakarta-commons and others.
- It is not yet documented, so I don't close the issue.
A/ To test the new plugin you must download/install it :
maven plugin:download
-Dmaven.repo.remote=http://cvs.apache.org/repository
-DgroupId=maven
-DartifactId=maven-ant-plugin
-Dversion=SNAPSHOT
B/ Recreate the ant script (maven ant) and define your dependencies in the
build.properties like :
commons-pool.jar=${commons-pool.home}/commons-pool.jar
...
...
Craig, for the problem with clean target, I think that we can :
1) download jars in another directory like ${project.home}/dl_lib
2) add a target like clean-all which delete the target and the dl_lib
directories.
The problem with this, will be if the user changes a library and doesn't call
the clean-all target. He'll have the 2 jars in the classpath :-(
Do you have another idea ?
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/MPANT-20?page=comments#action_28915
---------------------------------------------------------------------
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: Thu, 13 Jan 2005 7:01 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]
