dependabot[bot] on npm_and_yarn
Bump highlight.js from 9.15.6 t… (compare)
alexarchambault on gh-pages
Update website (compare)
alexarchambault on master
remove Stream (#1921) `Iterabl… (compare)
$ cs resolve --sbt-plugin com.typesafe:sbt-mima-plugin:0.7.0 com.typesafe:mima-core_2.12:0.7.0:default com.typesafe:sbt-mima-plugin;sbtVersion=1.0;scalaVersion=2.12:0.7.0:default org.scala-lang:scala-compiler:2.12.10:default org.scala-lang:scala-library:2.12.10:default org.scala-lang:scala-reflect:2.12.10:default org.scala-lang.modules:scala-xml_2.12:1.0.6:default
Has coursier recently had a fix for redirect or proxy basic auth? sbt 1.3.13 is failing but 1.4.0-M1 works.
Yes, credentials handling was made more loose by coursier/coursier#1756. It's kind of less secure IMO, but it seems these defaults are what users expect.
Is there any way to make the cs exectutable work on alpine docker images?
@joan38 I think GraalVM native images don't work out-of-the-box from alpine. oracle/graal#386 has possible workarounds (haven't tried them).
sbtnow goes to
org.scala-sbtwhich requires a redirect to either typesafe or bintray and this does not work. I thought I had an issue explaining but can't find it now - too many things going on. Anyway, it looks like it goes to the first no problem with auth and then gets the redirect which works but then does not provide the auth when it goes through the proxy to the redirect.
I am trying to run my own jar using coursier offline using a cache using something like:
cs launch --cache lib --extra-jars build/Main.jar --main-class Main -- "$@“
But it fails to find the Scala standard library. I don’t have this problem when I run
cs launch in the normal way.
cp -r lib ~/.cache/coursier/v1 cs launch --mode offline --extra-jars /usr/local/share/scala/lib build/Main.jar --main-class Main -- "$@“
COURSIER_CONFIG_DIRto a custom location and set the
COURSIER_CACHEto a subdirectory of the config directory. In the config directory I have
credentials.propertiesfiles. All these settings seem to take but artifact resolution is still failing. I have 2 issues, authentication against our inhouse Artifactory instance is still not working and I cannot figure out how to map the ivy path needed to resolve the
emoji_2.12package which for some reason uses non-standard ivy and has been mirrored to our Artifactory instance with the same messing structure.
-vvvvto up the log verbosity but this isn’t helping, this my be because coursier is still at the stage where it is trying to bring down its dependencies first.
coursierChecksums := Nil
cs fetch org.scalariform:sbt-scalariform:1.8.3however it fails with a resolution error despite the artifact being on central: https://search.maven.org/artifact/org.scalariform/sbt-scalariform/1.8.3/jar. Any ideas as to what I'm doing wrong?
./cs fetch -r jitpack com.github.outwatch.outwatch:outwatch:master-SNAPSHOTbut didn't work
~$ cs launch org.scalameta::scalafmt-cli:2.4.2 -- --help Exception in thread "main" coursier.jvm.ErrnoException: Errno Permission denied (13) at coursier.jvm.Execve.execve(Execve.java:33) at coursier.cli.launch.Launch$.$anonfun$launchFork$9(Launch.scala:121) at coursier.cli.launch.Launch$.$anonfun$launchCall$10(Launch.scala:345) at coursier.cli.launch.Launch$.run(Launch.scala:534) at coursier.cli.Coursier$.$anonfun$runA$2(Coursier.scala:128) at coursier.cli.Coursier$.$anonfun$runA$2$adapted(Coursier.scala:112) at coursier.cli.CommandAppPreA.run(CommandAppPreA.scala:22) at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$5(CommandAppWithPreCommand.scala:99) at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$5$adapted(CommandAppWithPreCommand.scala:99) at scala.util.Either.fold(Either.scala:191) at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$3(CommandAppWithPreCommand.scala:99) at caseapp.core.app.CommandAppWithPreCommand.$anonfun$main$3$adapted(CommandAppWithPreCommand.scala:85) at scala.Option.foreach(Option.scala:407) at caseapp.core.app.CommandAppWithPreCommand.main(CommandAppWithPreCommand.scala:85) at coursier.cli.Coursier$.main(Coursier.scala:77) at coursier.cli.Coursier.main(Coursier.scala)
cs, no change.
coursierworks fine, just not the native launcher.
csworks ok on its own, it just seems unable to fork the JVM.
~$ cs Coursier 2.0.0-RC6-24 Usage: cs [options] [command] [command-options] Available commands: bootstrap, complete, fetch, get, install, java, java-home, launch, list, publish, resolve, setup, uninstall, update Type cs command --help for help on an individual command
cs install ammonite --scala 2.12.12?
--scalaargument is supported for
cs launchetc, but not for
aarch64as an architecture in coursier? I found there is a guard to only explicitly allow
"x86_64" | "amd64"here: https://github.com/coursier/coursier/blob/master/modules/jvm/src/main/scala/coursier/jvm/JvmIndex.scala#L82
csbuild associated to the releases?