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

        Hide
        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
        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
        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
        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
        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
        Felipe Leme added a comment -

        Re-assigning it...

        Show
        Felipe Leme added a comment - Re-assigning it...
        Hide
        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
        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
          • Votes:
            4 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: