Maven 2.x Ant Tasks

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

Attachments

  1. File
    MANTTASKS-18_new.diff
    10/Jun/07 3:35 PM
    6 kB
    Herve Boutemy
  2. File
    MANTTASKS-18_new.tgz
    10/Jun/07 3:35 PM
    3 kB
    Herve Boutemy
  3. File
    MANTTASKS-18_new2.diff
    12/Jun/07 4:27 PM
    5 kB
    Herve Boutemy
  4. Text File
    patch.txt
    19/Jan/06 10:26 AM
    2 kB
    Michael Hartmeier

Issue Links

This issue is duplicated by:
MANTTASKS-137 <dependencies> task gives a bad pathId when downloading a deployed SNAPSHOT Blocker Closed
MANTTASKS-68 artifact:depencies doesnt work with Snapshot Major Closed
MANTTASKS-1 dependencies ant task incorrectly handles transitive snapshot dependencies Major Closed
This issue relates to:
MANTTASKS-1 dependencies ant task incorrectly handles transitive snapshot dependencies Major Closed
This issue is related to:
MNG-2961 DefaultArtifact getBaseVersion is changed to "xxxx-SNAPSHOT" only if you first call isSnapshot() Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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

Vote (19)
Watch (20)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.