sbt/ivy failing to resolve wildcard ivy dependencies on a filesystem resolver
Asked Answered
S

1

6

I am using the ~/.sbt/repositories file to tell sbt 0.13.5 which repositories to retrieve from. That file only contains local and a file:// repository with a custom layout that closely resembles the standard sbt one, with sbtVersion and scalaVersion optional fields represented.

When it comes to resolving dependencies for my project, I've noticed weird behavior:

  • Resolving exact dependencies works fine
  • latest.integration also works fine
  • Wildcard resolution of the form x.y.+ doesn't find anything, and instead seems to be searching for literal patterns. I get errors of the form:
    [warn] ==== myrepo: tried
    [warn]   file://path/to/my/repo/myorg/mypackage_2.10/[revision]/ivy-[revision].xml
    [info] Resolving myorg#mypackage_2.10;2.7.1.+ ...
    [warn]  module not found: myorg#mypackage_2.10;2.7.1.+

which as you can see, mention the repo layout pattern explicitly.

I'm mostly confused because the resolver works fine for anything but the + wildcard dependencies. I tried poking around the ivy documentation to figure out if certain resolvers (like the file:// resolver I'm using) don't implement certain kinds of dependency resolution, but that didn't seem to be a thing, so I'm mostly stumped. Any idea what I can do to make it work, or what might be causing it?

Swivel answered 21/8, 2014 at 13:59 Comment(2)
Interesting. Can you put a small reproducible sample on github?Boomer
github.com/sbt/sbt/issues/2279Lugar
A
2

I had a problem similar to this in the past. We had one or more applications we would build all of which used the same Ivy2 Cache. If we used wildcards in those builds, we would sometimes get a situation where it could would not resolve the dependencies correctly. It only caused problems when we used wildcards. Everything else worked just fine.

The problem we discovered was that in certain circumstances the Ivy2 Cache would become corrupt. Generally the solution was to delete the offending libraries from the Ivy2 Cache. Then if we ran the build again it would work.

I eventually discovered a post which hinted that some operations on the Ivy2 Cache are not thread safe. I.E. Running multiple builds simultaneously could in some cases corrupt the cache. We ended up setting custom Ivy Cache folders for all our builds. This fixed the problem.

Sorry, I can't find the original post that led me down that path, but the posts below may be somewhat related.

https://groups.google.com/forum/#!topic/simple-build-tool/eCOkACPjm9E https://groups.google.com/forum/#!topic/simple-build-tool/wFXhJcngy9Y

Anemology answered 27/8, 2014 at 15:30 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.