These are chat archives for sbt/sbt

17th
Nov 2016
Filippo De Luca
@filosganga
Nov 17 2016 10:15

Hi Guys, I need to generate a pom with a different list of dependencies, is any way to do it? I have tried to write:

libraryDependencies in makePom := Seq.empty

But it does not work as I tough

erd17
@erd17
Nov 17 2016 10:27
how to address this warning trait Build in package sbt is deprecated: Use .sbt format instead?
Jakub Liska
@l15k4
Nov 17 2016 11:43
hey, is compile->test dependency possible? Say you have an example project that needs to use test classes of the core project
test->testworks, test->compile too, but compile->test doesnt
Dale Wijnand
@dwijnand
Nov 17 2016 12:09
@l15k4 compile->test works for me
Jakub Liska
@l15k4
Nov 17 2016 12:10
core/src/test/SomeMock.scala
example/src/main/Main.scala -> needs to use `SomeMock``
Dale Wijnand
@dwijnand
Nov 17 2016 12:10
Those should be core/src/test/scala/SomeMock.scala and example/src/main/scala/Main.scala
Jakub Liska
@l15k4
Nov 17 2016 12:10
example.dependsOn(core % "compile->compile;compile->test")
ah, yes, sry ... still, example doesn't compile ... I'm using 0.13.9
Dale Wijnand
@dwijnand
Nov 17 2016 12:13

build.sbt

scalaVersion in ThisBuild := "2.12.0"

val core = project
val example = project dependsOn (core % "compile->test")

core/src/test/scala/A.scala

object A { def foo = 1 }

example/src/main/scala/B.scala

object B { def main(args: Array[String]): Unit = println(A.foo) }

project/build.properties

sbt.version=0.13.13

Running it:

> example/run
[info] Running B
1
Jakub Liska
@l15k4
Nov 17 2016 12:17
ah, got it, .dependsOn(core % "compile->test") works, .dependsOn(core % "compile->compile;compile->test") doesn't
thanks !
Dale Wijnand
@dwijnand
Nov 17 2016 12:25
No compile->compile;compile->test works as well
(the "->compile" is implied so it simplifies to "compile;compile->test" which also works)
Jakub Liska
@l15k4
Nov 17 2016 12:48
what the ... ok, you are right, not sure what happened but it works now ...
erd17
@erd17
Nov 17 2016 14:32
unmanagedSourceDirectories in FuncTest <<= (baseDirectory in FuncTest)(base => Seq(base / "func")), The operator <<= is deprecated but I have no idea how to convert the above expression to the new syntax. Any help please?
Dale Wijnand
@dwijnand
Nov 17 2016 14:36
unmanagedSourceDirectories in FuncTest := Seq((baseDirectory in FuncTest).value / "func")
erd17
@erd17
Nov 17 2016 14:39
@dwijnand cheers
I'm also getting a warning about using trait Build, what should be used instead?
Dale Wijnand
@dwijnand
Nov 17 2016 14:40
build.sbt
erd17
@erd17
Nov 17 2016 14:41
I read some discussions that scala build files are a good thing and a lot of projects use them, such as ensime
is it worth it to learn a DSL when you can use plain scala
Dale Wijnand
@dwijnand
Nov 17 2016 14:42
The DSL is minimal, but very convenient.
For instance you don't need to import either sbt or any of the plugins you might be using
nor do you have to define things in object and vals/defs
just plain, top-level expressions

so

scalaVersion in ThisBuild := "2.12.0"

instead of

import sbt._, Keys._

object Build extends Build {
  val myProject = project in file(".") settings (
    scalaVersion in ThisBuild := "2.12.0"
  )
}
erd17
@erd17
Nov 17 2016 14:55
thanks, I tried to read the sbt documentation once but it is not easy to learn it
Dale Wijnand
@dwijnand
Nov 17 2016 15:03
ensime is moving to build.sbt too: ensime/ensime-sbt#265
Mirco Dotta
@dotta
Nov 17 2016 15:17

I’ve the following build.sbt

lazy val root = (project in file("."))
  .settings(packagedArtifacts := Map.empty)
  .aggregate(akka)

lazy val akka = uri("git://github.com/akka/akka#v2.4.12")

Which causes the following error when loading the build

Cloning into '/Users/mirco/.sbt/0.13/staging/c106b727f177c676bb38/akka-sample-camel-java'...
fatal: remote error: 
  %s is not a valid repository name
  Email support@github.com for help
java.lang.RuntimeException: Nonzero exit code (128): git clone --depth 1 git://github.com/akka/akka-samples/akka-sample-camel-java /Users/mirco/.sbt/0.13/staging/c106b727f177c676bb38/akka-sample-camel-java
    at scala.sys.package$.error(package.scala:27)
    at sbt.Resolvers$.run(Resolvers.scala:134)

Am I doing something clearly wrong?

Dale Wijnand
@dwijnand
Nov 17 2016 15:43
well git://github.com/akka/akka-samples/akka-sample-camel-java isn't a valid clone URL
Dale Wijnand
@dwijnand
Nov 17 2016 15:51
@dotta got it. Akka's build defines some projects as ProjectRef(file(s"akka-samples/$name"), name), that's interacting with the source dependency feature..
Mirco Dotta
@dotta
Nov 17 2016 15:52
is that a bug in sbt, or something to fix in the akka build?
(btw, thanks for looking into this!)
and, is there a workaround to the current problem?
Dale Wijnand
@dwijnand
Nov 17 2016 15:53
A bug in sbt
clearly it's working for them in Akka
Mirco Dotta
@dotta
Nov 17 2016 15:54
what’s funny is that I believe the akka project was successfully cloned, but then sbt goes on trying to clone git://github.com/akka/akka-samples/akka-sample-camel-java, which is not a valid repo as you mentioned
Dale Wijnand
@dwijnand
Nov 17 2016 15:54
For a workaround.. it depends on what you're willing to change :) I don't use sbt's source dependency / staging feature. I use ProjectRef(dir, projectName), using paths to checkouts on my filesystem. That works nicely (it even imports in IntelliJ! :O)
Yep, it's miss-using the ProjectRef there
Mirco Dotta
@dotta
Nov 17 2016 15:55
I can probably make that work. What’s the easiest way to checkout a git tag with sbt?
Basically, I would have to checkout tags before the build file is loaded
Dale Wijnand
@dwijnand
Nov 17 2016 15:56
When do you want to check it out?
Mirco Dotta
@dotta
Nov 17 2016 15:56
when loading the build
Dale Wijnand
@dwijnand
Nov 17 2016 15:56
uhm.. you could do it in the onLoad of the metabuild...
Mirco Dotta
@dotta
Nov 17 2016 15:56
yep, that’s what I thought
ok, otherwise maybe I’ll just script the repos I want to check out
definitely a lot easier :)
Thanks Dale, we definitely need to grab a :beer: one of these days!
Dale Wijnand
@dwijnand
Nov 17 2016 15:58
OH "I'll just bash script it, it'll be a lot easier" ... FML :)
Mirco Dotta
@dotta
Nov 17 2016 15:58
haha :)
Dale Wijnand
@dwijnand
Nov 17 2016 15:58
@dotta sure, where are you?
Mirco Dotta
@dotta
Nov 17 2016 15:58
Lausanne
But I should be at Scala eXchange, in case you are planning to go
(I’m assuming you live in London)
Dale Wijnand
@dwijnand
Nov 17 2016 15:59
(yep) I might be getting tickets, but I definintely plan to meet people at the pub after the event
Mirco Dotta
@dotta
Nov 17 2016 15:59
Awesome. Looking forward to it!
Michal Bigos
@teliatko
Nov 17 2016 16:39
@RomanIakovlev I’m again. I just want to let you know that it worked, but … now I have another problem.
Hi all, when I’m extending Test configuration like: lazy val XyTest = config(“xy") extend(Test) and then defining settings as inConfig(XyTest)(Defaults.testSettings), how can I instrument xy:compile just to compile /src/xy and not also /src/test?
Michal Bigos
@teliatko
Nov 17 2016 16:45
I’ve already tryied to filter config.classpath in compileInputs in (compile in Xy), but it does not work. It’s ignored at all.
Does anybody have an idea?
Dale Wijnand
@dwijnand
Nov 17 2016 16:47
I think that's what extend means
Michal Bigos
@teliatko
Nov 17 2016 16:48
My point is that I want to have a configuration, which has the same libraryDependencies as Test and all the tasks etc. but I do not want to compile /src/test.
Is that possible?
Dale Wijnand
@dwijnand
Nov 17 2016 16:51
yes, don't make it extend Test and define the dependencies also in that configuration
Michal Bigos
@teliatko
Nov 17 2016 16:53
You mean libraryDependencies in Xy := …?
Dale Wijnand
@dwijnand
Nov 17 2016 16:53
no libraryDependencies += scalaTest % "test;xy"
Michal Bigos
@teliatko
Nov 17 2016 16:55
I’m doing that in plugin and basically the only purpose of this configuration should be to add additional test framework. User should use its own default test framework, thats why I’m extending Test.
Dale Wijnand
@dwijnand
Nov 17 2016 16:56
Not sure what you mean
Michal Bigos
@teliatko
Nov 17 2016 16:58
Ok I will prepare a short example to explain what I mean exactlly.
Michal Bigos
@teliatko
Nov 17 2016 17:04
Thanks so far
RomanIakovlev
@RomanIakovlev
Nov 17 2016 18:14
@teliatko sorry, I haven’t ever used extend. But if you just need the library dependencies from Test configuration, wouldn’t the following work? (libraryDependencies in Xy) ++= (libraryDependencies in Test)? Or maybe (libraryDependencies in Test).value.
Owen Healy
@ellbur
Nov 17 2016 18:47
@vpetro Yes that does seem to be exactly the thing. Thanks!
Owen Healy
@ellbur
Nov 17 2016 18:52
Is there any way to redirect output from a command, for example show dependencyTreeString, to a file?
Sam Smoot
@sam
Nov 17 2016 18:57
@ellbur I kinda doubt it from within SBT, but if you started it with $ sbt 2>&1 | tee -a out.log you could probably log your entire session?
Dale Wijnand
@dwijnand
Nov 17 2016 19:00
There's a plugin
Rob Norris
@tpolecat
Nov 17 2016 20:17
sbt new scala/scala-seed.g8 gets to Minimum Scala build. and then seems to hang forever. Is this a known issue? I'm using the latest sbt-extras.
Derek Wickern
@dwickern
Nov 17 2016 20:28
i'm using FileFunction.cached to cache the transformation of one file. sometimes, the cache is empty. how could this happen? is the cache getting corrupted?
def transform(file: File): File = ???
val cache = FileFunction.cached(cacheDir) { files => Set(transform(files.head)) }
cache(Set(oneFile)) // returns an empty set
Dale Wijnand
@dwijnand
Nov 17 2016 20:42
@tpolecat No, it's not. Worked for me right now. Did it get any further on your machine in the mean time?
Rob Norris
@tpolecat
Nov 17 2016 20:43
@dwijnand huh, curious. I tried Daniel's g8 thing and it hung too, just after displaying the title. Does it work for you with sbt-extras?
Dale Wijnand
@dwijnand
Nov 17 2016 20:43
yes
Rob Norris
@tpolecat
Nov 17 2016 20:43
I don't have any global plugins at all. Thought that might be the issue but I deleted them.
Hmmmmmmm
Dale Wijnand
@dwijnand
Nov 17 2016 20:44
If it stops there, it sounds like a giter8 problem maybe.
Open an issue and @eed3si9n, maybe he can provide some diagnostic methods for you.
Rob Norris
@tpolecat
Nov 17 2016 20:44
Will do, thank you.
eugene yokota
@eed3si9n
Nov 17 2016 20:44
Giter8 uses JGit, so that might cause some issue
Dale Wijnand
@dwijnand
Nov 17 2016 20:44
I believe he knows giter8 at least a bit more than me. np
eugene yokota
@eed3si9n
Nov 17 2016 20:45
Dale Wijnand
@dwijnand
Nov 17 2016 20:46
"Minimum Scala build." comes from https://github.com/scala/scala-seed.g8/blob/2.12.x/src/main/g8/default.properties#L2, so I would assume the JGit'ing went well
eugene yokota
@eed3si9n
Nov 17 2016 20:46
so it could be JLine?
Rob Norris
@tpolecat
Nov 17 2016 20:48
sbt work fine otherwise, and it's all jliney
curious
Dale Wijnand
@dwijnand
Nov 17 2016 20:48
hmm, good thinking. @tpolecat try removing/moving you ~/.inputrc?
eugene yokota
@eed3si9n
Nov 17 2016 20:48
my output looks like this:
$ sbt new scala/scala-seed.g8
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512M; support was removed in 8.0
[info] Loading global plugins from /Users/eugene/dotfiles/sbt/0.13/plugins
[info] Set current project to quick-test (in build file:/Users/eugene/work/quick-test/)
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Minimum Scala build.

name [My Something Project]:

Template applied in ./my-something-project
you don't get to name [My Something Project]:?
Rob Norris
@tpolecat
Nov 17 2016 20:49
I don't have a ~/.inputrc
No, hang on.
tmp$ sbt new scala/scala-seed.g8
[info] Loading global plugins from /Users/rnorris/.sbt/0.13/plugins
[info] Set current project to tmp (in build file:/private/tmp/)
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Minimum Scala build.
that's all i get
the missing blank line might be a clue, dunno
aha, if i hit enter i get

name [My Something Project]:
Template applied in ./my-something-project
So maybe it is JLine.
This is the default mac terminal app.
Maybe I have something in my environment that's messing it up. Looking.
eugene yokota
@eed3si9n
Nov 17 2016 20:53
I used to get odd sbt terminal related issues when JLine jars gets messed up under sbt's boot directory
switching between sbt version somehow corrupted a JAR over newer or older version
Rob Norris
@tpolecat
Nov 17 2016 20:54
Huh ok, I can clear that out. What should I nuke?
I did just change from 0.13.13.-RC2 to 0.13.13
eugene yokota
@eed3si9n
Nov 17 2016 20:54
~/.sbt/boot/
that's where sbt downloads sbt JARs
Rob Norris
@tpolecat
Nov 17 2016 20:55
Hm, nope. Same behavior.
eugene yokota
@eed3si9n
Nov 17 2016 20:57
what about:
$ shasum -a 256 ~/.sbt/boot/scala-2.10.6/lib/jline.jar
mine is 813f2bc34a096cc7780c6946acf401c82e739cf9d5359edf414f74662137d3b1
Rob Norris
@tpolecat
Nov 17 2016 20:57
same
jvm 1.8.0_65-b17
eugene yokota
@eed3si9n
Nov 17 2016 20:58
mine is 1.8.0_91, but I don't know if that makes the differece
could you file an issue here? so you'll know if we get around to fixing or reproducing it - https://github.com/foundweekends/giter8/issues
Rob Norris
@tpolecat
Nov 17 2016 21:00
Yep. I was going to try it with "raw" g8 but the installation instructions don't work.
I'll open an issue for that too I guess ;-)
Jeff May
@jeffmay
Nov 17 2016 23:21
I'm working on a semantic versioning plugin that uses MiMa to detect whether the changes in the working directory are major, minor, or patch, and I'm wondering if it is possible to alter the version settingKey for the lifetime of the publish task
is it possible to change the value of a settingKey for the lifetime of a task?
having the plugin compile all the code at boot to determine the correct value for the version key is too disruptive to the developer, but we need to run this before publishing a version
Dale Wijnand
@dwijnand
Nov 17 2016 23:23
no, it's a restriction
tasks aren't even defined while settings are being defined
but your plugin sounds really interesting, you could make it simply enforce that the version is correct, according to its calculations
Jeff May
@jeffmay
Nov 17 2016 23:29
yea, that's the approach that we went
but then it runs into other issues
so the thought was that we have some maxVersion flag. If you want to make a breaking change, you just bump this version
Dale Wijnand
@dwijnand
Nov 17 2016 23:31
is this public?
Jeff May
@jeffmay
Nov 17 2016 23:31
not yet, unfortunately
the issue is that we also have another plugin that uses library shading by enforcing versioned packages and versioned artifact names
that plugin uses the version key to determine what the versioned package names should be
and then we run into a chicken and egg problem
Dale Wijnand
@dwijnand
Nov 17 2016 23:33
you should make it public, sounds interesting to me :)
Jeff May
@jeffmay
Nov 17 2016 23:33
yea, I would love for it to be open source
we're in talks about open sourcing more of our stuff
this would be top on the list of things
Dale Wijnand
@dwijnand
Nov 17 2016 23:33
I created https://github.com/dwijnand/sbt-dynver recently, which is at least in the same domain
Jeff May
@jeffmay
Nov 17 2016 23:35
I need it because I maintain some other libs we use internally that come from public projects and I would like to add these tools, but instead I have to use my own tools and then delete those tool and settings in the forked version
kinda of a waste of time and a pain in my a$$
but anyway, I'll post to this chat room if we decide to open source it
yea, our plugin is a lot like dynver
it uses git tags as well
Dale Wijnand
@dwijnand
Nov 17 2016 23:37
cool, maybe it can absorb it :)
Jeff May
@jeffmay
Nov 17 2016 23:37
so I guess the answer is that the shading plugin needs to be aware of the version that semver thinks it should be, and not what our versioning plugin uses (note that I put syntax highlighting on all the plugin names)
so we can't use the version settingKey for this
maybe we could define a publishVersion task that calculates the version it should publish
but then how would we use that version when publishing?
I guess I would have to define an override for publish?
publish := {
  // fork a process of sbt with the version set to whatever and run publish?
}
but then how we would prevent it from running forever?
Jeff May
@jeffmay
Nov 17 2016 23:44
I guess we could use a separate task:
val calculateVersion = taskKey[String]("...")
calculateVersion := { ... }
publishAuto := {
  val version = calculateVersion.value
  // fork a process of sbt with the version set to whatever and run publish with version
}