So the suggested behaviour is to not produce <get>'s if a jar override is in place and use a <copy>?

Or could one override the src <get> uses when using an overriden jar.

The problem is I think in the get-deps build.jelly template.

<j:forEach var="dep" items="${pom.dependencies}">
<!-- note: this is a valid use of artifactDirectory -->
<get
src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
dest="$${libdir}/${dep.artifact}"
usetimestamp="true"
ignoreerrors="true"
/></j:forEach>

See http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin-resources/templates/build.jelly?rev=1.17&view=markup

+1 on getting this fixed.

I've got a similar scenario: we've got two Maven repositories defined in maven.repo.remote. One is ibiblio, the other is a private one accessible only within the organizational domain.

When organizational users try to build a source distribution with ant, the build fails to get the dependencies because the first repository is used from maven.repo.remote, due to this code:

<!-- get first repo in the list -->
<u:tokenize var="repos" delim=",">${maven.repo.remote}</u:tokenize>
<j:set var="repo">${repos[0]}</j:set>

Although not elegant, a workaround might be to generate each "get" with each repository (making M times N <get>'s for M repositories and N dependencies), and hope that timestamps prevent the unnecessary downloads.

I have tweaked it so that included jar's that are used via jar override are resolved properly. Instead of a get, a copy is done instead. I am using this successfully to build commons-email's "build.xml" file.

I tried to assign this to myself and got a jira exception.

Re-assigning it...

David, your fix seems to be good. Can we close this issue ?

Fixed. Will be reopened if necessary.