by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 2015 11:10
    japgolly commented #2066
  • Jun 22 2015 08:25
    keepscoding commented #2044
  • Jun 21 2015 03:24
    xerial commented #157
  • Jun 21 2015 00:10
    eed3si9n unlabeled #2057
  • Jun 21 2015 00:10

    eed3si9n on 0.13

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 3 more (compare)

  • Jun 21 2015 00:10
    eed3si9n closed #2057
  • Jun 21 2015 00:10

    eed3si9n on fixbuild

    (compare)

  • Jun 20 2015 18:42
    eed3si9n synchronize #2057
  • Jun 20 2015 18:42

    eed3si9n on fixbuild

    Fix typo (compare)

  • Jun 20 2015 18:23

    eed3si9n on fixbuild

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 1 more (compare)

  • Jun 20 2015 18:23
    eed3si9n synchronize #2057
  • Jun 20 2015 14:59

    eed3si9n on scalaversionbump

    (compare)

  • Jun 20 2015 14:59

    eed3si9n on 0.13

    Bumping up Scala version to 2.1… Try to keep bincompat Fixes #1666 and 1 more (compare)

  • Jun 20 2015 14:59
    eed3si9n unlabeled #2068
  • Jun 20 2015 14:59
    eed3si9n closed #2068
  • Jun 20 2015 14:59
    eed3si9n closed #1666
  • Jun 20 2015 14:57
    eed3si9n commented #2068
  • Jun 20 2015 12:55
    dwijnand commented #2068
  • Jun 20 2015 04:51
    eed3si9n synchronize #2068
  • Jun 20 2015 04:51

    eed3si9n on scalaversionbump

    Fixes #1666 (compare)

OlegYch
@OlegYch
cool
Stefan Wachter
@swachter

I have two plugins that both are based on the ScalaJS plugin. The first plugin depends on version 1.0.1 of the plugin whereas the second depends on version 1.1.1. Without any measures version 1.0.1 is used. What conflict resolution strategy does SBT apply?

When I add a libraryDependency in plugins.sbt on version 1.1.1 then version 1.1.1 is used. Is this the correct way to resolve such dependency conflicts between plugins?

Justin Reeves
@justinallenreeves

is there a way to iterate and filter over libraryDependencies? I'm inheriting a bunch of common deps in a multiproject and I'd like to just specify something like

val commonDeps = Seq (
  "org" %% "a" % "1.0.0",
  "org" %% "b" % "1.0.0",
  "org" %% "c" % "1.0.0",
)
val testDeps = Seq()
val commonSettings = Seq(
lazy val commonSettings = Seq(
  organization := ???,
  resolvers += "Typesafe repository" at "http://repo.typesafe.com/typesafe/releases/",
  scalacOptions ++= Seq(
    "-feature",
    "-deprecation",
    "-unchecked",
    "-Ywarn-unused-import"
  ),
  libraryDependencies ++= commonDeps ++ testDependencies
)

lazy val projA = (project in file("projA").settings(commonSettings)
lazy val projB = (project in file("projB").settings(commonSettings).settings(libraryDependencies := ???) //pull from what's in commonSettings but filter because we only need "b"

that way common dependencies are declared once and have common versions, but I won't always need all of them in every project

>>=
@fommil
o/ could somebody please tell me what is the state of the git source dependency features like discussed here https://github.com/sbt/sbt/labels/source%20dependencies ? I recently tried to use this feature (as a consumer) for a library that has never published to sonatype, and although sbt cloned the repo it complained about missing ivy files. Is there something missing on my side as the consumer, or something missing on the library side?
OlegYch
@OlegYch
well it works for me
>>=
@fommil
:confounded:
@OlegYch do you have an example of it working? I've used it in the past but I think this time the ivy/pom stuff is what is confusing it. I'm on sbt 1.3.13.
OlegYch
@OlegYch
make sure both projects use same sbt version
>>=
@fommil
ooh, will do
nope, still getting the missing ivy/pom thing
(I deleted the staging directory)
lazy val thing = ProjectRef(uri("https://gitlab.com/REDACTED/REDACTED.git#REDACTED"), "REDACTED")

lazy val root = (Project("root", file("."))).dependsOn(thing)
is how I'm using it
the exception is in at lmcoursier.CoursierDependencyResolution.unresolvedWarningOrThrow(CoursierDependencyResolution.scala:249)
OlegYch
@OlegYch
does the project build successfully on its own?
>>=
@fommil
yes
I can share it with you privately if you're interested in looking into it.
oh, wait, maybe it's a scala version thing
I just realised that it's looking for 2.12 stuff but the library is set up to use 2.13
(that seems an unfortunate restriction... same sbt and scala versions necessary?)
huzzah! That was it. I don't suppose there is a way to cross over scala versions ?
I know it compiles on 2.12 as well
>>=
@fommil
@OlegYch thanks anyway! Your suggestion to check the sbt version prompted me to check the Scala version too and that fixed it.
OlegYch
@OlegYch
great
i'm not sure if crossbuilding is well supported in this setting
Arsene
@Tochemey
Hello geeks, can I get some help for sbt-ci-release? I am having some issue on travis releasing a lib:
2020-07-02 18:18:55.194Z  info [SonatypeClient] Created successfully: iosuperflat-1003  - (SonatypeClient.scala:125)
2020-07-02 18:18:55.218Z error [Sonatype] 
java.io.IOException: Supplied file /home/travis/build/super-flat/lagom-pb/target/sonatype-staging/0.3.0+0-b8a3fd7b+20200702-1818-SNAPSHOT is a not an existing directory!
1 reply
Eric K Richardson
@ekrich
@steinybot I found this and tried it in JAVA_OPTS env var but no luck, weird. https://stackoverflow.com/questions/41505219/unable-to-tunnel-through-proxy-proxy-returns-http-1-1-407-via-https
Down below in Java 8 they changed the Basic auth setup requiring this.
Jason Pickens
@steinybot
@ekrich Your probablem wasn’t limited to the JVM though was it? curl also failed.
Eric K Richardson
@ekrich
I got curl to work so it is definitely the JVM setup.
I had to add the Basic auth --proxy-user user:pass and -L for the redirect.
and make sure the https-proxy env var was set correctly.
Eric K Richardson
@ekrich
@steinybot Unbelievably, upgrading to 1.4.0-M2 worked. Maybe the version of coursier has changed and fixed the problem. I knew @eed3si9n was good.
Eric K Richardson
@ekrich
Maybe I need to put in an issue?
softshipper
@softshipper
Hi all
Does it exist a sbt docker container?
Andriy Plokhotnyuk
@plokhotnyuk
Lorenzo Gabriele
@lolgab
Hi everyone :-)
Do you know any workaround when two plugins use two incompatible versions of the same dependency?
In my case sbt-guardrail and sbt-sonatype use two incompatible versions of jackson-* libraries and sonatypeBundleRelease fails.
OlegYch
@OlegYch
update them to use latest version
softshipper
@softshipper
@plokhotnyuk Thanks
Lorenzo Gabriele
@lolgab
@OlegYch They are transitive dependencies on both projects. So it's not easy to align them.
I found a workaround which is to add a depedency override in CI right before running the sonatype publishing command:
echo "dependencyOverrides += \"com.fasterxml.jackson.core\" % \"jackson-databind\" % \"2.9.10.1\"" > project/workaround.sbt          
sbt sonatypeBundleRelease
OlegYch
@OlegYch
weird dependecyOverrides doesn't usually fix things
Lorenzo Gabriele
@lolgab
In this case it does because I'm not using the other plugin here. I know it's a bad workaround :( But it's the best I could get..
Daniel Spiewak
@djspiewak
I have a main method which is await()ing a CountDownLatch, and I'm running this with fork := false and cancelable := true. When I hit Ctrl-C, sbt does cancel the runtime, but I'm actually at a loss as to exactly what it's doing since it doesn't appear to be using Thread#interrupt() on the main thread! I've attempted to wrap the await() in a try/catch which handles InterruptedException and the handler is simply never fired. Am I missing something?
Daniel Spiewak
@djspiewak
Dredging through the code, it looks like this is ultimately coming from ExecutorService#shutdownNow(), which claims to be using Thread#interrupt()
But like… I'm catching interruption and not seeing it, so I'm very perplexed as to how this is possible without using weird functions like stop()
Daniel Spiewak
@djspiewak
Oh… it's just literally not interrupting anything
that explains so much
objektwerks
@objektwerks
I just noticed SBT 1.3.13 is not provided via Homebrew. Anyone else notice? Or am I missing something? Thanks!
Daniel Spiewak
@djspiewak

As a follow-up to my previous… it appears that sbt just doesn't correctly interrupt run-main threads. This is supposed to happen in EvaluateTask… but doesn't. I don't know why. The threads are interruptible (I checked), and interrupt() is being called, it's just not, like, happening.

Anyway, with significant shenanigans, you can detect the presence of sbt's unforked runner within your application… and trigger your own interrupts:

    if (Thread.currentThread().getName().startsWith("run-main")) {
      try {
        // the security manager will be sbt.TrapExit; use its classloader to jailbreak out and find sbt.EvaluateTask
        val klass = System.getSecurityManager().getClass().getClassLoader().loadClass("sbt.EvaluateTask$")

        val EvaluateTask = klass.getDeclaredField("MODULE$").get(null).asInstanceOf[{ val currentlyRunningEngine: AtomicReference[AnyRef] }]
        val currentEngine = EvaluateTask.currentlyRunningEngine

        val outer = Thread.currentThread()

        val monitor = new Thread({ () =>
          var continue = true
          while (continue)  {
            if (currentEngine.get() == null) {
              continue = false
              outer.interrupt()
            }
            Thread.sleep(100)
          }
        })

        monitor.setName("sbt-unforked-interrupt-monitor")
        monitor.setPriority(Thread.MIN_PRIORITY)
        monitor.setDaemon(true)

        monitor.start()
      } catch {
        case _: Throwable => ()   // literally swallow anything that moves... (it probably means our detection failed, or sbt changed its internals)
      }
    }

This assumes you're setting interrupt handlers properly on your main thread, which you should be in case sbt ever fixes this bug. This is basically just a busy-wait workaround to the fact that the interruption never seems to actually happen.

At any rate, this also has the handy side-effect of fixing sbt's current issues with memory leaks coming out of run
hrj
@hrj
Is there a way in sbt to pin the contents of an artifact? Similar to this gradle plugin: checksum dependency plugin