Maven 1.x Ant Plugin

ant-plugin not obeying jar override

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.9
  • Labels:
    None
  • Environment:
    Sun JDK1.3.1 on windows. Maven from cvs on March 24, 2003
  • Number of attachments :
    0

Description

When using the ant-plugin to generate an ant build file, the generated <get> tags do not obey the jar overrides specified in project.properties. All <get> tags attempt to load the jars from ibiblio even though an override was specified that points to the local harddrive. Overrides are being used because the jar files in question are proprietary and cannot be uploaded to ibiblio.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
dion gillard added a comment -

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

Show
dion gillard added a comment - So the suggested behaviour is to not produce <get>'s if a jar override is in place and use a <copy>?
Hide
Permalink
Jerome Lacoste added a comment -

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

Show
Jerome Lacoste added a comment - Or could one override the src <get> uses when using an overriden jar.
Hide
Permalink
Jerome Lacoste added a comment -

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

Show
Jerome Lacoste added a comment - 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
Hide
Permalink
Sean Kelly added a comment -

+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.

Show
Sean Kelly added a comment - +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.
Hide
Permalink
David Eric Pugh added a comment -

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.

Show
David Eric Pugh added a comment - 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.
Hide
Permalink
Felipe Leme added a comment -

Re-assigning it...

Show
Felipe Leme added a comment - Re-assigning it...
Hide
Permalink
Arnaud Heritier added a comment -

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

Show
Arnaud Heritier added a comment - David, your fix seems to be good. Can we close this issue ?
Hide
Permalink
Arnaud Heritier added a comment -

Fixed. Will be reopened if necessary.

Show
Arnaud Heritier added a comment - Fixed. Will be reopened if necessary.

People

  • Assignee:
    David Eric Pugh
    Reporter:
    Mike Bowler
Vote (4)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: