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

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

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

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

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="$

"/>

<javac srcdir="$

" destdir="$

"
classpath="$

;$

"
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

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

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?

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.

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

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="$

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

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

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.

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.

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