Use Coursier to install from Artifactory

Question
1

Hey good morning,

I’m trying to use Coursier to install packages from behind an enterprise Artifactory instance. I’m able to use fetch / resolve the artifacts from the Artifactory instance, but setup / install aren’t working. It gives me an error like

“Can’t Find a scala version suffix for io.get-coursier::coursier-cli:latest.release”

after running coursier install coursier.

I can see it pull artifacts from my Artifactory instance. I’m thinking that once it fetches the io.get-coursier:apps package, it’s directed to download the artifacts from Maven Central, and then craps out. Setting up the mirror.properties file hasn’t seemed to help it resolve from the Artifactory instance.

The Maven packages in this instance do have a Scala version suffix (ex. 2.12_1.0), which may be related to the error?

I’m using the COURSIER_REPOSITORIES and COURSIER_CREDENTIALS variables to set up authentication with my Artifactory instance, and COURSIER_MIRRORS to direct it to my mirror.properties file.

Seems like Coursier & Artifactory docs are…sparse, so if anyone’s gone through this before, I’d appreciate any guidance. Thank you!

2

Wild guess: maybe something like this: Coursier resolution of Scala 3 dependencies - #3 by sageserpent-open is causing the problem?

That was down to me using an outdated version of Coursier, had to reinstall a brand new version to fix it.

Other than that, I presume you’ve already seen this: Proxy and mirrors | Metals or something similar as you’ve mentioned COURSIER_MIRRORS?

If you do find a solution, please share it back - Kinetic Merge is packaged as a Coursier application, and I’d like to know what to tell people if they are working in corporate firewall land.

EDIT: then again, there is: Coursier is unable to determine Scala version when cut off from the public Internet · Issue #2838 · coursier/coursier · GitHub , which also looks a bit like your problem…

1 Like
3

I’ll be sure to keep this updated. That GitHub issue you shared is the most promising sign. That seems to be exactly my issue, or at least closely related.

I looked at your other post, and I don’t think that’s what causing my issue. I’ve been able to use resolve successfully, it’s just install / setup (I guess anything that’s trying to make an executable) that is having a hard time.

I’ll keep following that thread and will report back if I find any solutions.

1 Like
4

Also tried with coursier install –no-default -r https://<repo-name>.com/… coursier and that failed as well with the Scala version issue above.

5

Does enabling verbose logging give any clues?

6

Not that I noticed. It typically just expanded the stack trace. Interestingly, on occasion, it would download from my org’s Artifactory instance, but once it finished that download it would pivot to downloading from Maven Central and other public repositories. I think it has something to do with how the Coursier Apps is set up.

ex) I have an io.getcoursier.apps package in Artifactory with a apps-1.0.65.jar artifact. This artifact shows multiple JSON files for different packages, like metals, sbt, scalafmt, etc.

Here’s an example file, scalafmt.json, which I believe is the default.

{
  "mainClass": "org.scalafmt.cli.Cli?",
  "repositories": [
     "central"
   ],
  "dependencies": [
     "org.scalameta::scalafmt-cli:latest.stable"
   ]
}

My idea is that if I could override that repositories variable, I could get it to work. I just don’t know that it would be advisable / feasible to republish the artifact, nor do I really know how I’d go about that immediately.

7

Okay. So. Ultimately, my XY problem is that I was trying to get scala-steward-action to work properly, but it uses Coursier to install things like scalafmt.

I could not get Coursier to work correctly from my organization’s network / Artifactory.

My approach has been to not use the scala-steward-action (which is primarily intended for public-facing projects) and to use a custom action with the scala-steward Docker image (which I can pull from Artifactory). This is working (mostly) as intended, as of now.

This seems like an issue with Coursier, and a reliance on the availability of public repos, which just won’t work for my use case. Largely, our team has migrated off of using Coursier to manage / install packages for Scala projects.

If you are reading this in the future and Coursier has identified a solution, please update this thread. I will not be pursuing this any more at this time.