Maven lets you `deploy` snapshot builds of an upstream component, then give a timestamped snapshot version as the dependency version in a downstream component’s POM. This works fine for command-line builds: the exact requested version will be downloaded to the local repository on demand and used, ignoring any other locally `install`ed snapshot builds.

But it does not work as expected in the NetBeans editor; if the IDE has a record of the source location of the upstream project (as is likely), it will try to associate the dependency with the source project. So long as you have not made any changes to the upstream project since deployment, this may be OK, but if you have—for example, switched the upstream sources back to trunk from a branch—the IDE will treat the current source project as authoritative (`preferSources`), potentially leading to error badges and the like in the downstream project’s source files, even though they are buildable by `mvn`.

Using `apisupport.projectinspector` I found that this is not a problem with `MavenForBinaryQueryImpl` per se; it is correctly reporting a source association for something like `~/.m2/repo/grp/art/1.0-SNAPSHOT/art-1.0-SNAPSHOT.jar`. The problem is that `CompileClassPathImpl` is reporting that as the dependency artifact’s file, while in reality it is something like `~/.m2/repo/grp/art/1.0-SNAPSHOT/art-1.0-20170503.012345-1.jar` (which `MavenForBinaryQueryImpl` rightly ignores).

This bug makes it complicated and confusing to use timestamped snapshots in complex chains of multimodule branchy development.