These are chat archives for sbt/sbt

10th
Oct 2015
Perry
@pfn
Oct 10 2015 00:23
@matanster the changes do not persist unless you return the updated state
@matanster and no, you cannot change settings of a sub task from a task
unless you're doing hacky crap like calling Project.runTask directly
matanster
@matanster
Oct 10 2015 01:54
I feel like I should find a good resource about state.
Perry
@pfn
Oct 10 2015 02:11
state is precisely that... and object that represents the world
an
Fayi Femi-Balogun
@fayimora
Oct 10 2015 03:02
Hello, how do I pass in program arguments in sbt?
Perry
@pfn
Oct 10 2015 03:31
for what
Fayi Femi-Balogun
@fayimora
Oct 10 2015 03:36
My project relies on a config flag, “-config.file=blahblah”. Was just trying out sbt-assembly and realised it ran the project. As a result, the assembly task crashes because there is no config flag.
Also, if i wanted to run the project from terminal(i’ve been using intellij), “sbt run -config.flag=blah” doesn’t do the trick
Perry
@pfn
Oct 10 2015 04:13
assembly doesn't run your project...
and you would set javaOptions in run
and you would need to set fork in run
Perry
@pfn
Oct 10 2015 04:24
@fayimora
Fayi Femi-Balogun
@fayimora
Oct 10 2015 04:52
@pfn thanks i’ll have a look in a few hours, already 6am here in london :sleepy:
matanster
@matanster
Oct 10 2015 10:42
had anyone encountered trouble importing a library inside an sbt plugin? I seem to be getting "NoClassDefFoundError" at plugin runtime, for classes defined in a library the sbt plugin depends on. The plugin compiles, but seems that its library dependency isn't brought into its runtime environment.
matanster
@matanster
Oct 10 2015 10:59
with compiler plugins, I published a fat jar that packs in the library dependencies. is that necessary with sbt plugins as well? or would sbt fetch their library dependencies into the classpath at plugin runtime?
Perry
@pfn
Oct 10 2015 12:13
no
er, yes fatjar not necessary
Fayi Femi-Balogun
@fayimora
Oct 10 2015 13:46
javaOptions in run ++= Seq("-Dconfig.file=dev.conf")

javaOptions in test ++= Seq("-Dconfig.file=test.conf")
Isn’t this the right way to specify arguments in the build file? It works for run but not test.
Seth Tisue
@SethTisue
Oct 10 2015 13:48
probably you have fork true for run but not for test? javaOptions will only have any effect if a new JVM is forked
Fayi Femi-Balogun
@fayimora
Oct 10 2015 13:48
@SethTisue I had for for run but i changed it to fork := true. Shoudln’t that fork every task?
Seth Tisue
@SethTisue
Oct 10 2015 13:49
no, that’s not how settings in sbt work
Fayi Femi-Balogun
@fayimora
Oct 10 2015 13:50
so i guess i have to specify:
fork in run := true

fork in test := true
Seth Tisue
@SethTisue
Oct 10 2015 13:50
well, now I’m starting to wonder. and google.
Fayi Femi-Balogun
@fayimora
Oct 10 2015 13:51
haha ok. I think i tried that before and it didn’t work, will try again
Seth Tisue
@SethTisue
Oct 10 2015 13:52
I think it’s fork in Test with a capital T
a setting is only configurable on a particular task if that task is written to look for a task-scoped setting
I think the test task expects to look up the fork setting in the Test configuration
> set fork in test := true
[info] The new value will be used by no settings or tasks.
> set fork in Test := true
[info] The new value will be used by test:run::runner, test:testGrouping
this gets especially bewildering because in code you distinguish the test task from the test configuration using the capital letter, but then in the stuff that sbt repeats back to you, test: indicates that it’s a configuration because colon.
and then there’s some magic I forget by which just saying test by itself is equivalent to test:test
Seth Tisue
@SethTisue
Oct 10 2015 13:58
this stuff is a lot more discoverable if you fool with interactively first using set and inspect instead of just droppping it directly into your build config files. you get a lot more feedback when you’re working interactively
Fayi Femi-Balogun
@fayimora
Oct 10 2015 14:02
Thanks a lot Seth! I didn’t know about set and inspect…
after 2 mins of playing around, I realised what i wanted was fork in (Test, test) := true because as you said, test is actually test:test
Seth Tisue
@SethTisue
Oct 10 2015 14:17
aha, nice. I’ve learned and forgotten that several times: that when you just say test it runs test:test, but the same delegation doesn’t happen with set
SRGOM
@SRGOM
Oct 10 2015 15:42
QQ: Is it correct that IO.copy( file1, file2 ) throws if and only if both file1 and file2 are absent, and not just if file1 is absent?
Perry
@pfn
Oct 10 2015 15:42
dunno, read the source
SRGOM
@SRGOM
Oct 10 2015 15:43
Actually that's what my quick snippet tells me
Perry
@pfn
Oct 10 2015 15:43
that's generally my solution for working with sbt at all
SRGOM
@SRGOM
Oct 10 2015 15:43
I understand, and that's a valid answer
I was prefacing my question with this, my actual question would be, why is the design like this?
pfn @pfn shrugs
Perry
@pfn
Oct 10 2015 15:45
if the behavior is odd, it's generally justified in a comment
Moses Nakamura
@mosesn
Oct 10 2015 18:25
good morning. I’m having trouble resolving a transitive dependency–sbt is only looking for it locally, but I know it exists on a remote host. I’m on sbt 0.13.8, any idea why it might do that? looking at the stack trace has not been terribly helpful, and I can’t figure out from the last output what is pulling it in. show dependency-tree doesn’t show the jar I’m looking for, so I think it might be pulled in by an sbt plugin . . . and that’s about as far as I’ve gotten in trying to debug the problem.
matanster
@matanster
Oct 10 2015 19:33

@mosesn

but I know it exists on a remote host

have you tried confirming that once by explicitly pulling it through an explicit libraryDependency?
can you supply more details?

matanster
@matanster
Oct 10 2015 19:40

Question about caching by sbt and ivy:

Does sbt cache (local) dependencies in some configurations but not others?
Is there any best practice for avoiding local caching by sbt?

I've been going in circles around very odd phenomena, working with interdependent artifacts publishing and resolving from my local ivy for a while (admittedly not a vanilla setup as it involved compiler and sbt plugins sharing some of their library dependencies).

Circumstantially, things seemed to have went back to normal after I cleared my ~/.ivy2/local/ and copies of the same local artifacts that showed up under ~/ivy2/cache (When exactly does ivy cache local dependencies?). Also I found some .cache files at the root of some of the sbt projects, which I also deleted at the same time.

matanster
@matanster
Oct 10 2015 19:47
Well, I guess General Troubleshooting Steps might answer some of my question, and also help @mosesn
Perry
@pfn
Oct 10 2015 19:50
@mosesn if you have it local, it will always resolve local first
matanster
@matanster
Oct 10 2015 19:50
Moved my question to http://stackoverflow.com/questions/33058264/avoiding-library-dependencies-caching-in-sbt, as it may be of some generic interest.
matanster
@matanster
Oct 10 2015 19:56
@pfn thanks for your prior advice on state
Perry
@pfn
Oct 10 2015 19:56
@matanster can you edit your messages a little less please? it's pretty unreadable for me
matanster
@matanster
Oct 10 2015 19:57
I apologize for that. Yes.
Moses Nakamura
@mosesn
Oct 10 2015 19:57
@matanster no, I haven’t tried with libraryDependencies–I think it’s pulled in by an sbt plugin. I confirmed by actually curling the endpoint.
Perry
@pfn
Oct 10 2015 19:57
I use the irc gateway most of the time
and edits just repeat the message over and over
Moses Nakamura
@mosesn
Oct 10 2015 19:58
what kind of details?
matanster
@matanster
Oct 10 2015 19:58
@pfn thanks for informing me about that
Moses Nakamura
@mosesn
Oct 10 2015 19:58
@pfn right, the problem is that I don’t have it locally
Perry
@pfn
Oct 10 2015 19:59
mosesn, you've never published local?
mosesn, I don't see how it. can be confused then
Moses Nakamura
@mosesn
Oct 10 2015 20:01
@pfn hmm, how does it tell if you have it locally? is there an index it checks? maybe the index is out of date (like maybe it got invalidated but the index was not updated)
Perry
@pfn
Oct 10 2015 20:01
@mosesn remote resolvers are never skipped
unless it has been found locally previously
Moses Nakamura
@mosesn
Oct 10 2015 20:02
@pfn how does it know if it has been found locally previously?
Perry
@pfn
Oct 10 2015 20:02
then it will always resolve local until versions change, or you nuke the local copy
I don't know, that's your environment problem
er, and yeah indices
Moses Nakamura
@mosesn
Oct 10 2015 20:02
where’s the index? maybe I can nuke it?
Perry
@pfn
Oct 10 2015 20:05
how about pasting the failure to resolve? it tells you everywhere it's looked
and that would be ~/.ivy2/
you don't want to nuke it...
Moses Nakamura
@mosesn
Oct 10 2015 20:06
one sec
how should I paste it?
just directly in here?
[info] downloading https://artifactory.twitter.biz/repo1.maven.org/com/googlecode/javaewah/JavaEWAH/0.7.9/JavaEWAH-0.7.9.jar ...
[debug]     maven2: downloading https://artifactory.twitter.biz/repo1.maven.org/com/googlecode/javaewah/JavaEWAH/0.7.9/JavaEWAH-0.7.9.jar
[debug]     maven2: downloading https://artifactory.twitter.biz/repo1.maven.org/com/googlecode/javaewah/JavaEWAH/0.7.9/JavaEWAH-0.7.9.jar.sha1
[debug] sha1 OK for https://artifactory.twitter.biz/repo1.maven.org/com/googlecode/javaewah/JavaEWAH/0.7.9/JavaEWAH-0.7.9.jar
[info]     [SUCCESSFUL ] com.googlecode.javaewah#JavaEWAH;0.7.9!JavaEWAH.jar(bundle) (128ms)
[debug]         tried file:/Users/mnakamura/.m2/repository/org/apache/httpcomponents/httpclient/4.1.3/httpclient-4.1.3.jar
[warn]     [NOT FOUND  ] org.apache.httpcomponents#httpclient;4.1.3!httpclient.jar (0ms)
[warn] ==== Maven2 Local: tried
[warn]   file:/Users/mnakamura/.m2/repository/org/apache/httpcomponents/httpclient/4.1.3/httpclient-4.1.3.jar
[debug]         tried https://artifactory.twitter.biz/repo1.maven.org/org/slf4j/slf4j-api/1.7.2/slf4j-api-1.7.2.jar
[info] downloading https://artifactory.twitter.biz/repo1.maven.org/org/slf4j/slf4j-api/1.7.2/slf4j-api-1.7.2.jar ...
[debug]     maven2: downloading https://artifactory.twitter.biz/repo1.maven.org/org/slf4j/slf4j-api/1.7.2/slf4j-api-1.7.2.jar
[debug]     maven2: downloading https://artifactory.twitter.biz/repo1.maven.org/org/slf4j/slf4j-api/1.7.2/slf4j-api-1.7.2.jar.sha1
[debug] sha1 OK for https://artifactory.twitter.biz/repo1.maven.org/org/slf4j/slf4j-api/1.7.2/slf4j-api-1.7.2.jar
[info]     [SUCCESSFUL ] org.slf4j#slf4j-api;1.7.2!slf4j-api.jar (136ms)
[debug]         tried file:/Users/mnakamura/.m2/repository/org/apache/httpcomponents/httpcore/4.1.4/httpcore-4.1.4.jar
[warn]     [NOT FOUND  ] org.apache.httpcomponents#httpcore;4.1.4!httpcore.jar (1ms)
[warn] ==== Maven2 Local: tried
[warn]   file:/Users/mnakamura/.m2/repository/org/apache/httpcomponents/httpcore/4.1.4/httpcore-4.1.4.jar
[debug]         tried file:/Users/mnakamura/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
[debug]     [NOT REQUIRED] commons-logging#commons-logging;1.1.1!commons-logging.jar
[debug]         tried https://artifactory.twitter.biz/repo1.maven.org/org/scoverage/scalac-scoverage-plugin_2.10/1.1.0/scalac-scoverage-plugin_2.10-1.1.0.jar
[info] downloading https://artifactory.twitter.biz/repo1.maven.org/org/scoverage/scalac-scoverage-plugin_2.10/1.1.0/scalac-scoverage-plugin_2.10-1.1.0.jar ...
[debug]     maven2: downloading https://artifactory.twitter.biz/repo1.maven.org/org/scoverage/scalac-scoverage-plugin_2.10/1.1.0/scalac-scoverage-plugin_2.10-1.1.0.jar
[debug]     maven2: downloading https://artifactory.twitter.biz/repo1.maven.org/org/scoverage/scalac-scoverage-plugin_2.10/1.1.0/scalac-scoverage-plugin_2.10-1.1.0.jar.sha1
[debug] sha1 OK for https://artifactory.twitter.biz/repo1.maven.org/org/scoverage/scalac-scoverage-plugin_2.10/1.1.0/scalac-scoverage-plugin_2.10-1.1.0.jar
I’m resolving to an artifactory on my intranet, which proxies repo1.maven.org
Perry
@pfn
Oct 10 2015 20:10
take out the mavenLocal resolver
Moses Nakamura
@mosesn
Oct 10 2015 20:12
ok, trying
Perry
@pfn
Oct 10 2015 20:24
I've never understood, what's the point of mirroring central? is it to be a good citizen and decrease load?
or to limit developer access to Internet?
Perry
@pfn
Oct 10 2015 20:35
I suppose bandwidth is a concern as well
matanster
@matanster
Oct 10 2015 20:35
Or a zombie attack that affects central during work hours
Moses Nakamura
@mosesn
Oct 10 2015 20:43
yeah, I think it’s a security thing
and bandwidth
it caches artifacts too, I think
also, we publish our artifacts to the same place, so I think it simplifies configuration
so will removing the maven-local specification mean that it doesn’t cache anything?
dang, I gotta run. thanks for your help folks, will follow up later.
Perry
@pfn
Oct 10 2015 20:53
no, but your mavenLocal seems to think it is canonical for the artifact you're looking for @mosesn