3

I published some libraries using sbt publishLocal it worked and published to my ~/.ivy2/local dir.

I then have a project that depends on these libraries but sbt update can't find them.

specifically, my project has these dependencies:

lazy val myDependencies = commonDependencies ++ Seq(
    "my.corp"  %% "lib1" % "1.0.1-SNAPSHOT" withSources () withJavadoc (),
    "my.corp"  %% "lib2" % "2.0.2-SNAPSHOT" withSources () withJavadoc ()
  )

sbt update has this error: 

[error] (services / update) lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: Error fetching artifacts:
[error] file:////home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar: not found: /home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar
[error] file://///home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar: not found: /home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar

when I look in the dir I can see the published jars but their name has the scala version appended, which is why the update resolving fails, I think :

$ ls /home/myuser/.ivy2/local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars
lib1_2.12.jar  lib1_2.12.jar.md5  lib1_2.12.jar.sha1

$ ls /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars
lib2_2.12.jar  lib2_2.12.jar.md5  lib2_2.12.jar.sha1

If I publish to a repo for real I can resolve the libs.

Does anyone know the sbt incantation to fix this? ;-)

Cheers Karl

Update:- I think coursier is the problem, not sure how to tell it to look for lib2_2_12.jar. Could it have a bad cached reference?

Caused by: lmcoursier.internal.shaded.coursier.cache.ArtifactError$NotFound: not found: /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar

Update:- disabling coursier worked from the sbt REPL I can run

sbt:my-project> set ThisBuild / useCoursier := false

and then

sbt:my-project> update

and that worked, but setting it back to true update failed again, so this looks like a coursier issue.

Update: coursier fetch from the command line worked!!

coursier fetch my.corp::lib1:1.0.1-SNAPSHOT --no-default -r central -r ivy2Local

downloaded the transitive dependencies and found my jar in my local ivy2 dir

so this is back to looking like an sbt - coursier interaction issue

Karl
  • 1,164
  • 9
  • 25
  • which SBT version do you use? BTW, it is totally normal that the files have a Scala binary version suffix in their name. – cbley Feb 11 '20 at 15:39
  • 1
    v1.3.8, Thanks, I understand that adding the version to the name is normal (and that %% appends to the name in the dependency, but then why is update looking for a file without the scalaversion in the name? it's odd. – Karl Feb 11 '20 at 20:35
  • 1
    You can try disabling coursier with `useCoursier := false` in your `build.sbt`. – cbley Feb 12 '20 at 08:17
  • Hey thanks, I ran `set ThisBuild / useCoursier := false` in my sbt REPL the `update` from the REPL and it worked... looks like a coursier bug or sbt need to let coursier know the name to look for when resolving from local – Karl Feb 13 '20 at 00:53
  • is there an issue in the sbt or coursier repos to track this problem? – Seth Tisue Apr 17 '20 at 13:30
  • Hey Seth, I tried to reduce my build down to a small problem to package up in git repo so I could create an sbt issue as per their policy, but couldn't reproduce the issue in the small, though still an issue in my actual project.. I'll try again when i have some spare time. – Karl May 13 '20 at 00:48

1 Answers1

1

I've just now run into this and after lots of diffs between an older working version and this non-working version I figured out that it is the withSources() that triggers the bug in sbt and/or coursier.

joelsk
  • 11
  • 1
  • Thanks joelsk, I'll try removing it to test. I hacked past the issue by publishing my libs so that they were not publishLocal anymore, but it'll re-publish local and see if the issue returns then remove withSources() and test again. Cheers – Karl Jul 20 '20 at 13:30