Maven Ant Tasks
  1. Maven Ant Tasks
  2. MANTTASKS-18

filesetId does not contain all dependencies when artifact was not yet locally installed

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.6
    • Fix Version/s: 2.0.7
    • Component/s: dependencies task
    • Labels:
      None
    • Environment:
      java version "1.4.2_04", Linux 2.6.11.12, Apache Ant version 1.6.5
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      4

      Description

      In the artifact:dependencies task the filesetId is only correctly set, when the artifact was installed locally before running ant.

      After deletion of the local repository the dependant artifacts will be downloaded to the local repository, but only one of two dependant files will be included in the ant fileset. The classpath is set correctly.

      After running "mvn install" locally for the "as-base-launcher" maven project, ant computes the correct filesetId.

      The ant-project depends on the artifact "as-base-launcher" which itselfs depends only on classworlds. Snippets from ant buildfiles, poms and ant output follows:

      From the ant buildfile:

      <target name="launcherJAR" depends="init">
      <artifact:pom id="as-base.project" file="../poms/as-base.xml" />
      <artifact:dependencies filesetId="as-launcher.fileset" pathId="as-launcher.classpath" verbose="true">
      <pom refid="as-base.project"/>
      <remoteRepository refid="actisRepository" />
      </artifact:dependencies>

      <pathconvert property="mypath" targetos="unix">
      <path>
      <path refid="as-launcher.classpath" />
      </path>
      </pathconvert>
      <echo message="CLASSPATH: $

      {mypath}

      "/>

      <pathconvert property="myset" targetos="unix">
      <path>
      <fileset refid="as-launcher.fileset"/>
      </path>
      </pathconvert>
      <echo message="FILESET: $

      {myset}

      "/>
      </target>

      The referenced POM defining the ant dependencies:

      <project>
      <modelVersion>4.0.0</modelVersion>
      <groupId>actis</groupId>
      <artifactId>ant-as-base</artifactId>
      <version>1.0-SNAPSHOT</version>
      <dependencies>
      <dependency>
      <groupId>actis</groupId>
      <artifactId>as-base-launcher</artifactId>
      <version>1.0-SNAPSHOT</version>
      </dependency>
      </dependencies>
      <repositories>
      <repository>
      <id>actisRepository</id>
      <name>actisRepository</name>
      <url>http://company.com:9999/repository/</url>
      </repository>
      </repositories>
      </project>

      Output of the ant run:

      launcherJAR:
      actis:ant-as-base:jar:1.0-SNAPSHOT (selected)
      actis:as-base-launcher:jar:1.0-SNAPSHOT (selected)
      classworlds:classworlds:jar:1.1-alpha-1 (selected)
      [echo] CLASSPATH: /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar:/home/iwe/.m2/repository/actis/as-base-launcher/1.0-20051103.102305-8/as-base-launcher-1.0-20051103.102305-8.jar
      [echo] FILESET: /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar

      1. MANTTASKS-18_new.diff
        6 kB
        Herve Boutemy
      2. MANTTASKS-18_new.tgz
        3 kB
        Herve Boutemy
      3. MANTTASKS-18_new2.diff
        5 kB
        Herve Boutemy
      4. patch.txt
        2 kB
        Michael Hartmeier

        Issue Links

          Activity

          Hide
          Steve Metcalfe added a comment -

          I've had this problem too. Here's what i've found:
          Line 207 of DependenciesTask: filename = localRepo.pathOf(artifact)

          Returns (in my case):
          orange-portal/search-service/1.0-20051107.144552-1/search-service-1.0-20051107.144552-1.jar

          However the location of the jar that has been downloaded by the resolver is:
          orange-portal/search-service/1.0-SNAPSHOT/search-service-1.0-20051107.144552-1.jar

          Show
          Steve Metcalfe added a comment - I've had this problem too. Here's what i've found: Line 207 of DependenciesTask: filename = localRepo.pathOf(artifact) Returns (in my case): orange-portal/search-service/1.0-20051107.144552-1/search-service-1.0-20051107.144552-1.jar However the location of the jar that has been downloaded by the resolver is: orange-portal/search-service/1.0-SNAPSHOT/search-service-1.0-20051107.144552-1.jar
          Hide
          Michael Hartmeier added a comment -

          This isn't very nice, but it fixed the problem for me.
          Diff was against maven-artifact-ant 2.0.

          Show
          Michael Hartmeier added a comment - This isn't very nice, but it fixed the problem for me. Diff was against maven-artifact-ant 2.0.
          Hide
          Charles Paclat added a comment -

          I was seeing a similar problem when using the ant tasks. It seemed to me that the problem maybe somewhat further down the stack in that it when creating the new filename it was using the "baseVersion" and that was returning the timestamped version and not the actual base version. Applied the work around and it appeared to work for me as well though it did not seem like that was the correct fix for the problem...

          Show
          Charles Paclat added a comment - I was seeing a similar problem when using the ant tasks. It seemed to me that the problem maybe somewhat further down the stack in that it when creating the new filename it was using the "baseVersion" and that was returning the timestamped version and not the actual base version. Applied the work around and it appeared to work for me as well though it did not seem like that was the correct fix for the problem...
          Hide
          Dan Rollo added a comment -

          FWIW, I'm seeing this problem with v2.0.4, but BOTH the fileset and classpath attribs are incorrect (which also means no workaround exists that I can find).

          Below are the relevant snippets from a build, in case it helps. This was generated after deleting the bhatestutil dependency from my local repo.

          Path shown when fetching artifact from remote rep:
          ...util/1.0-SNAPSHOT/bhatestutil-1.0-20060422.014944-34.jar

          But then when the fileset is created for Ant, the (incorrect) path shown is:
          ...util/bhatestutil/1.0-20060422.014944-34/bhatestutil-1.0-20060422.014944-34.jar

          build.xml:

          <artifact:dependencies verbose="true" filesetId="fs.deps.test"
          pathId="cp.deps.test" useScope="test">
          <pom refid="maven.project"/>
          </artifact:dependencies>

          <property name="cp.compilet.kludge2" refid="cp.deps.test"/>
          <property name="classpath.compile.test"
          value="$

          {cp.compilet.kludge2}

          "/>

          <javac srcdir="$

          {dir.test}

          " destdir="$

          {dir.classes.test}

          "
          classpath="$

          {dir.classes}

          ;$

          {classpath.compile.test}

          "
          debug="on"
          optimize="off"
          deprecation="on"
          source="1.3"
          target="1.2"
          />

          Output from ant compile:

          [artifact:dependencies] Downloading:
          com/bhaweb/testutil/bhatestutil/1.0-SNAPSHOT/bhatestutil-1.0-20060422.01
          4944-34.jar
          [artifact:dependencies] Transferring 19K Adding reference: cp.deps.test
          Adding reference: fs.deps.test

          ...

          Setting project property: cp.compilet.kludge2 ->
          /home/dan/.m2/repository/com/bhaweb/testutil/bhatestutil/1.0-20060422.01
          4944-34/bhatestutil-1.0-20060422.014944-34.jar:/home/dan/.m2/repository/
          junit/junit/3.8.1/junit-3.8.1.jar:

          ...

          [javac] Using modern compiler
          dropping
          /home/dan/.m2/repository/com/bhaweb/testutil/bhatestutil/1.0-20060422.01
          4944-34/bhatestutil-1.0-20060422.014944-34.jar
          from path as it doesn't exist

          Show
          Dan Rollo added a comment - FWIW, I'm seeing this problem with v2.0.4, but BOTH the fileset and classpath attribs are incorrect (which also means no workaround exists that I can find). Below are the relevant snippets from a build, in case it helps. This was generated after deleting the bhatestutil dependency from my local repo. Path shown when fetching artifact from remote rep: ...util/1.0-SNAPSHOT/bhatestutil-1.0-20060422.014944-34.jar But then when the fileset is created for Ant, the (incorrect) path shown is: ...util/bhatestutil/1.0-20060422.014944-34/bhatestutil-1.0-20060422.014944-34.jar build.xml: <artifact:dependencies verbose="true" filesetId="fs.deps.test" pathId="cp.deps.test" useScope="test"> <pom refid="maven.project"/> </artifact:dependencies> <property name="cp.compilet.kludge2" refid="cp.deps.test"/> <property name="classpath.compile.test" value="$ {cp.compilet.kludge2} "/> <javac srcdir="$ {dir.test} " destdir="$ {dir.classes.test} " classpath="$ {dir.classes} ;$ {classpath.compile.test} " debug="on" optimize="off" deprecation="on" source="1.3" target="1.2" /> Output from ant compile: [artifact:dependencies] Downloading: com/bhaweb/testutil/bhatestutil/1.0-SNAPSHOT/bhatestutil-1.0-20060422.01 4944-34.jar [artifact:dependencies] Transferring 19K Adding reference: cp.deps.test Adding reference: fs.deps.test ... Setting project property: cp.compilet.kludge2 -> /home/dan/.m2/repository/com/bhaweb/testutil/bhatestutil/1.0-20060422.01 4944-34/bhatestutil-1.0-20060422.014944-34.jar:/home/dan/.m2/repository/ junit/junit/3.8.1/junit-3.8.1.jar: ... [javac] Using modern compiler dropping /home/dan/.m2/repository/com/bhaweb/testutil/bhatestutil/1.0-20060422.01 4944-34/bhatestutil-1.0-20060422.014944-34.jar from path as it doesn't exist
          Hide
          Ingo Weichsel added a comment -

          Our current workaround is to use the maven-artifact-ant-2.0-beta-3.jar and to call the dependencies task twice:

          <artifact:dependencies verbose="false">
          <pom refid="core.project"/>
          </artifact:dependencies>
          <artifact:dependencies filesetId="ajas_core.filesetId" pathId="ajas_core.classpath" verbose="true">
          <pom refid="core.project"/>
          </artifact:dependencies>

          This workaround does not work with later versions of maven-artifact-ant. Using such an old version of maven-artifact-ant may certainly have other side effects which i am not aware of...

          Show
          Ingo Weichsel added a comment - Our current workaround is to use the maven-artifact-ant-2.0-beta-3.jar and to call the dependencies task twice: <artifact:dependencies verbose="false"> <pom refid="core.project"/> </artifact:dependencies> <artifact:dependencies filesetId="ajas_core.filesetId" pathId="ajas_core.classpath" verbose="true"> <pom refid="core.project"/> </artifact:dependencies> This workaround does not work with later versions of maven-artifact-ant. Using such an old version of maven-artifact-ant may certainly have other side effects which i am not aware of...
          Hide
          Mark Hobson added a comment -

          I'm also getting similar issues whereby a dependency fileset is being populated with incorrect artifact paths when snapshot dependencies are not installed locally, i.e.:

          M2_REPO/groupId/artifactId/version-timestamp-build/artifactId-version-timestamp-build.type

          instead of:

          M2_REPO/groupId/artifactId/version-SNAPSHOT/artifactId-version-SNAPSHOT.type

          This bug is quite a blocker - especially since ant doesn't complain about some files missing when copying a fileset, resulting in incomplete dependencies being copied. Any idea when work will be started on this one?

          Show
          Mark Hobson added a comment - I'm also getting similar issues whereby a dependency fileset is being populated with incorrect artifact paths when snapshot dependencies are not installed locally, i.e.: M2_REPO/groupId/artifactId/version-timestamp-build/artifactId-version-timestamp-build.type instead of: M2_REPO/groupId/artifactId/version-SNAPSHOT/artifactId-version-SNAPSHOT.type This bug is quite a blocker - especially since ant doesn't complain about some files missing when copying a fileset, resulting in incomplete dependencies being copied. Any idea when work will be started on this one?
          Hide
          Chris Hilton added a comment -

          Did anyone verify or not if the patch is the "right" way to fix this? It seems to fix the path issues I've been having, but I'm wondering if I'm trading one set of problems for another. I'm also a bit concerned that this bug had its fix version removed; does that mean there's something wrong with the patch? As stated above, this is quite a blocker for those of trying to migrate from Ant.

          Show
          Chris Hilton added a comment - Did anyone verify or not if the patch is the "right" way to fix this? It seems to fix the path issues I've been having, but I'm wondering if I'm trading one set of problems for another. I'm also a bit concerned that this bug had its fix version removed; does that mean there's something wrong with the patch? As stated above, this is quite a blocker for those of trying to migrate from Ant.
          Hide
          Rick Riemer added a comment -

          As noted by Chris Hilton, MNG-1408 and MNG-2544 are possibly related.

          Show
          Rick Riemer added a comment - As noted by Chris Hilton, MNG-1408 and MNG-2544 are possibly related.
          Hide
          Peter Murray added a comment -

          I have encountered this problem too, but have more to share on it. The failure to properly use the SNAPSHOT part of the path to the file seems to be related to when there is a definition of a <remoteRepository> in the ant build file.

          <artifact:dependencies pathId="maven.dependencies" filesetId="dependency.fileset">
          <dependency groupId="com.tracegroup" artifactId="gui-tabs-and-docking" version="1.0-SNAPSHOT"/>
          <localRepository location="$

          {basedir}

          /dependencies"/>
          <remoteRepository refid="remote.repository"/>
          </artifact:dependencies>

          If the <remoteRepository> part was commented out (after the files were downloaded to the local repository) the paths would use SNAPSHOT as expected instead of the timestamp.

          Show
          Peter Murray added a comment - I have encountered this problem too, but have more to share on it. The failure to properly use the SNAPSHOT part of the path to the file seems to be related to when there is a definition of a <remoteRepository> in the ant build file. <artifact:dependencies pathId="maven.dependencies" filesetId="dependency.fileset"> <dependency groupId="com.tracegroup" artifactId="gui-tabs-and-docking" version="1.0-SNAPSHOT"/> <localRepository location="$ {basedir} /dependencies"/> <remoteRepository refid="remote.repository"/> </artifact:dependencies> If the <remoteRepository> part was commented out (after the files were downloaded to the local repository) the paths would use SNAPSHOT as expected instead of the timestamp.
          Hide
          Herve Boutemy added a comment -

          Here is a patch which does the same trick than the current patch, but a testcase is added to reproduce the problem

          Show
          Herve Boutemy added a comment - Here is a patch which does the same trick than the current patch, but a testcase is added to reproduce the problem
          Hide
          Herve Boutemy added a comment -

          Here is a new patch against latest revision in svn. It contains unit tests to check SNAPSHOT handling, one with uniqueVersion="false", one with uniqueVersion="true".
          The workaround in DependenciesTask is for uniqueVersion="true", which fails without it.
          It's only a workaround, since the resolved artifact should have baseVersion containing "-SNAPSHOT" and not "-timestamp": this issue needs more work to really be fixed.

          Show
          Herve Boutemy added a comment - Here is a new patch against latest revision in svn. It contains unit tests to check SNAPSHOT handling, one with uniqueVersion="false", one with uniqueVersion="true". The workaround in DependenciesTask is for uniqueVersion="true", which fails without it. It's only a workaround, since the resolved artifact should have baseVersion containing "-SNAPSHOT" and not "-timestamp": this issue needs more work to really be fixed.
          Hide
          Herve Boutemy added a comment -

          Yeah!
          looking for a real fix, I just found MNG-2961 DefaultArtifact getBaseVersion is changed to "xxxx-SNAPSHOT" only if you first call isSnapshot()

          That's it!!!
          Here is a new patch with this little workaround: simply call artifact.isSnapshot() before calculating filename.
          Unit test show that it works: cool.

          Now, the real bug is in MNG-2961, and the workaround in Maven Ant Tasks is really simple.

          Show
          Herve Boutemy added a comment - Yeah! looking for a real fix, I just found MNG-2961 DefaultArtifact getBaseVersion is changed to "xxxx-SNAPSHOT" only if you first call isSnapshot() That's it!!! Here is a new patch with this little workaround: simply call artifact.isSnapshot() before calculating filename. Unit test show that it works: cool. Now, the real bug is in MNG-2961 , and the workaround in Maven Ant Tasks is really simple.
          Hide
          Herve Boutemy added a comment -

          MNG-2961 is the bug causing us so much trouble.
          At least, the workaround is really easy (when you know it...)

          Show
          Herve Boutemy added a comment - MNG-2961 is the bug causing us so much trouble. At least, the workaround is really easy (when you know it...)

            People

            • Assignee:
              Unassigned
              Reporter:
              Ingo Weichsel
            • Votes:
              19 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: