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)

eugene yokota
@eed3si9n
@milessabin there was an old PR to move the code to com.jsuereth package, matching the organization id of the artifact, and I took the opportunity of 2.0.0 to apply it. it reflects the fact that sbt-pgp used to be maintained by Typesafe, but currently no one is actively looking at it.
Dale Wijnand
@dwijnand

@milessabin you might be using that class in a user-wide setting file in ~/.sbt.

Here's a diff I did in a private repo:

-com.typesafe.sbt.SbtPgp.autoImport.pgpPassphrase := Some("...".toCharArray)
+SettingKey[Option[Array[Char]]]("pgpPassphrase") in Global := Some("...".toCharArray)
That will make the user-wide setting work for old and new sbt-pgp
Miles Sabin
@milessabin
@dwijnand that was the first problem. Initially I updated the global version and was then baffled that the problem persisted, but not on all projects. It turned out that one of them used a plugin which pulled in sbt-ci-release which in turn pulled in sbt-pgp 1.1.2.
Dale Wijnand
@dwijnand
Right.
I don't think sbt-pgp should be globally enabled, personally.
It's a release plugin, so build-related, rather than a general sbt utility.
The fact that it has general utilities in it goes against what I said, though. I wish it were two (artifact) sbt plugins
Heikki Vesalainen
@hvesalai
Has there been a change in sbt from 1.0 -> 1.2 that would have made runMain to depend on package where it didn't do so previously?
Because now when we do runMain it triggers package which means that where it used to take 1sec to start main, now it takes 8secs
Miles Sabin
@milessabin
@dwijnand except that "globally" sort of means "locally" in this context, in the sense that it's not part of a published build configuration. I don't think it's completely unreasonable to treat publishing as orthogonal to building. For instance it's common to publish locally patched versions of components to private repos. In those circumstances it's extremely helpful to be able to do that without having to monkey with the upstream maintainers publishing configuration.
Dale Wijnand
@dwijnand
Do you need to add sbt-pgp to publish patched versions to private repos?
@hvesalai Could be. But I thought the change I'm thinking of was in 1.0.
Heikki Vesalainen
@hvesalai
@dwijnand what was that change? And indeed, it was between 0.13.18. and 1.2
Heikki Vesalainen
@hvesalai
using fgRunMain we are down to 4sec compared to runMain, but still 4x slower than 0.13.18
Miles Sabin
@milessabin
@dwijnand it's a policy choice :-)
Dale Wijnand
@dwijnand
@hvesalai looks like you found it, that fg/bg thing in an attempt to support multiple clients to sbt's server mode
@milessabin sounds niche. I think in the end of it, given Maven Central's importance and its need for signed artifacts it's probably long-time better to fold it into sbt proper. Along with other sonatype-specific fascilities, like staging and closing repos.
Miles Sabin
@milessabin

it's probably long-time better to fold it into sbt proper. Along with other sonatype-specific fascilities, like staging and closing repos.

:100:

eugene yokota
@eed3si9n
I'd probably go for sbt-gpg route today since sbt-pgp does too many things as Daniel said
Dale Wijnand
@dwijnand
yeah either or, the point is "signing jars" should be in sbt
eugene yokota
@eed3si9n
do you wanna add it to the roadmap? - https://discuss.lightbend.com/t/roadmap-for-sbt-1-4/5038
Dale Wijnand
@dwijnand
sure
Yifan Xing
@xingyif
Hi there, I am trying to migrate FiloDB (https://github.com/filodb/FiloDB) from 0.13 to 1.3.
In sbt 1.x, sbt Build trait is deprecated and the settings in previous .scala files all need to be moved to .sbt files.
Is there a standard for how to separate different settings into different sbt files? Any examples? (e.g., how to separate FiloBuild and FiloSettings)
nafg
@nafg
@xingyif you can still have project/*.scala files
You just don't define the projects there. Just make objects there and you can use them in the .sbt files
So you can define settings and any other scala code there
OlegYch
@OlegYch
looks like you can just move FiloBuild object content into build.sbt and remove extends Build in FiloSettings
Yifan Xing
@xingyif
Ah I see, is it because FlioBuild is defining the project and therefore should go into build.set and FiloSettings can be kept in the .scala files because it contains objects that FiloBuild needs?
OlegYch
@OlegYch
right
Ethan Atkins
@eatkins
@hvesalai are you running sbt fgRun or are you running fgRun from the sbt shell?
sbt 1.x starts up 3-4 seconds slower than 0.13.x on my computer
eugene yokota
@eed3si9n
@xingyif also some of the common setting things like scalaVersion and organization can move to ThisBuild / x. see https://www.scala-sbt.org/1.x/docs/Using-Sonatype.html#step+4%3A+Configure+build.sbt
another convention that might be helpful is tracking all the dependencies in one file - https://www.scala-sbt.org/1.x/docs/Organizing-Build.html#Tracking+dependencies+in+one+place
OlegYch
@OlegYch
how can i silence "insecure HTTP request is deprecated" for repositories in ~/.sbt/repositories ?
Yifan Xing
@xingyif
@OlegYch @nafg @eed3si9n thanks a lot! Trying out the new changes and doing some local testing : )
eugene yokota
@eed3si9n
@OlegYch you can't until we support opt-in in launcher configuration
OlegYch
@OlegYch
oh ok
eugene yokota
@eed3si9n
@/all please check this out. Lightbend Community Code of Conduct - https://discuss.lightbend.com/t/lightbend-community-code-of-conduct-for-all-repos-under-sbt/5099
Anthony Cerruti
@srnb_gitlab
:tada:
Yifan Xing
@xingyif
I'm still trying to upgrade sbt 0.13 to 1.3. FiloDB depends on scalastyle (v1.0.0). Got this error not found: value scalastyleFailOnError
scalastyleFailOnError := true, in this file https://github.com/filodb/FiloDB/blob/develop/project/FiloSettings.scala#L61 at line 61.
I went through scalastyle doc http://www.scalastyle.org/sbt.html. Seems like scalastyleFailOnError filed still exists. Anyone know what's wrong?
Yifan Xing
@xingyif
Also in scalastyle doc (linked above): It says that scalastyle >= 0.9.0, should use testScalastyle := scalastyle.in(Test).toTask("").value. compare to scalastyle <= 0.8.0, testScalastyle := org.scalastyle.sbt.ScalastylePlugin.scalastyle.in(Test).toTask("").value.
I changed the code accordingly. But still got not found: value scalastyle. Insights?
Pyry-Samuli Lahti
@Pyppe
Howdy! Is there a way to change scalac options (e.g. remove `-Xfatal-warnings´) without sbt compiling everything again? We've got a toggle-command for this, but using it causes everything to be recompiled :/
Viktor Lund
@vilu
Hi, how do I specify specific settings for a specific scala version in a cross build?
Andriy Plokhotnyuk
@plokhotnyuk
@vilu you can try CrossVersion.partialVersion like here
Viktor Lund
@vilu
Perfect! thanks
eugene yokota
@eed3si9n
@xingyif here's a PR to your PR - xingyif/FiloDB#1
I think it was just missing import org.scalastyle.sbt.ScalastylePlugin.autoImport._
feel free to squash, take whatever parts you want