|
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}"> +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 --> 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. David, your fix seems to be good. Can we close this issue ? Fixed. Will be reopened if necessary. |
|||||||||||||||||||||||||||||||||||||||||
So the suggested behaviour is to not produce <get>'s if a jar override is in place and use a <copy>?