These are chat archives for sbt/sbt

20th
Oct 2015
Richard Gomes
@frgomes
Oct 20 2015 09:00
@jsuereth :: Thanks a lot :smile: One of those issues still need more clarification from my end. I will do that soon, or close it if not confirmed. Cheers :+1:
matanster
@matanster
Oct 20 2015 13:01
Is this technique supposed to work, for making a project depend on another one's PublishLocal?
compile in Compile in compilerPlugin <<= (compile in Compile in compilerPlugin).dependsOn(publishLocal in simpleGraph)
simpleGraph there is a library project, so I consume it through a library dependency, even though my master sbt project builds both.

What I get is the following, which seems to assume I understand how .sbt compilation imports stuff, which, I don't...

error: reference to compilerPlugin is ambiguous;
it is imported twice in the same scope by
import sbt._
and import $b4dfb791074016841c33._
compile in Compile in compilerPlugin <<= (compile in Compile in compilerPlugin).dependsOn(publishLocal in simpleGraph)

Perry
@pfn
Oct 20 2015 13:13
you defined compilerPlugin as a key, while the symbol is already imported
import sbt.{compilerPlugin =>,}
perhaps
matanster
@matanster
Oct 20 2015 13:30
That makes sense, because when I change the name of my project, the error goes away.
kind of a usability bug in sbt in that case, maybe.
matanster
@matanster
Oct 20 2015 13:35
Anyway having gotten over that, this line has no effect, probably because library dependencies are fetched before the compile command is evaluated.
Or for some other reason. Running compileon the sbt prompt, it just fails over resolving the library dependency, rather than first publishing the dependency.
matanster
@matanster
Oct 20 2015 13:50
Equivalently, inspect does not show the dependency has been added.
Perry
@pfn
Oct 20 2015 14:06
not a usability case
it's scala
because update is what fails
not compile
I'm pretty sure sbt tells you this
matanster
@matanster
Oct 20 2015 14:31

Would a dependency added that way show in inspect?

update in compilerPluginn <<= (update in compilerPluginn).dependsOn(publishLocal in simpleGraph)

Doesn't seem to affect the inspect output, and the compilestill fails in the update stage after adding it in build.sbt.

It has been once mentioned that provided should be used for consuming a library dependency in a similar situation.. frankly I am not sure why/how.
Perry
@pfn
Oct 20 2015 14:43
inspect is for task dependencies nothing more
or is that what you're asking
you're asking about library dependencies at the same time
matanster
@matanster
Oct 20 2015 14:45
I should probably take one step backward. My overarching goal in this attempt has been to accomplish a master build, which builds a library and projects that consume it. Right now, I manually manage without a unified build.
Which is error prone.
Conceptually, I assume this can be accomplished in either of two ways:
  1. have the projects consume the library classes directly from the classpath
  2. consume the library from a local ivy repository
This message was deleted
For the second way, which I tried above, although build.sbt compiles, nothing happens as intended - the update task isn't added with a dependency on first publishing the library.
Perry
@pfn
Oct 20 2015 14:52
why aren't you using dependsOn?
why go through the convoluted method of waiting for. publish and pulling from update
matanster
@matanster
Oct 20 2015 14:53
Here's by the way the full build.sbt. DependsOn is being used, but alone it doesn't solve it.
lazy val simpleGraph = (project in file("simpleGraph"))
lazy val compilerPluginUnitTestLib = (project in file("compiler-plugin-unit-test-lib"))
lazy val compilerPluginn = (project in file("compiler-plugin")).dependsOn(compilerPluginUnitTestLib, simpleGraph)
lazy val sbtPlugin = (project in file("sbt-plugin")).dependsOn(compilerPluginn)

update in compilerPluginn <<= (update in compilerPluginn).dependsOn(publishLocal in simpleGraph)
As I mentioned, methods that are less convoluted are most welcome. I am too ignorant to know what they are.
Perry
@pfn
Oct 20 2015 14:55
project in file("simpleGraph") dependsOn compilerPluginn
matanster
@matanster
Oct 20 2015 14:56
compilerPluginn depends on simpleGraph, not the other way around. It uses some of its classes.
Perry
@pfn
Oct 20 2015 14:58
Ok, then what about this doesn't work
without all the extraneous stuff
matanster
@matanster
Oct 20 2015 14:58
It looks like the dependency isn't added to compilerPluginn's update task...
Alternatively, how do people normally build projects that depend on a library, in a non-convoluted publish dependent way? I'd really like to master both ways.
Perry
@pfn
Oct 20 2015 15:01
just dependsOn (otherproject)
works perfectly fine
matanster
@matanster
Oct 20 2015 15:05
That's already inside lazy val compilerPluginn = (project in file("compiler-plugin")).dependsOn(compilerPluginUnitTestLib, simpleGraph) and doesn't work, even when I remove the update-tinkering line. I will prepare a minimal example out of this larger scheme I have there, and see what happens.

How do people normally build projects that depend on a library, in a non-convoluted publish dependent way? you may want one of your dependency project to also be a generic library, so I wonder if this intent is pathological or just no that frequently ocuring in the wild.
Perry
@pfn
Oct 20 2015 15:08
what is "doesn't" work
because project.dependsOn(otherproject) has worked in every single library I've ever worked with
matanster
@matanster
Oct 20 2015 15:09
[info] Updating {file:/repos/canve-master-build-play/}root...
[info] Updating {file:/repos/canve-master-build-play/}simpleGraph...
[info] Updating {file:/repos/canve-master-build-play/}compilerPluginUnitTestLib...
[info] Updating {file:/repos/canve-master-build-play/}compilerPluginn...
[info] Resolving canve#simple-graph_2.11;0.0.1 ...
[warn] module not found: canve#simple-graph_2.11;0.0.1
[warn] ==== local: tried
[warn] /home/matan/.ivy2/local/canve/simple-graph_2.11/0.0.1/ivys/ivy.xml
[warn] ==== activator-launcher-local: tried
[warn] /doesnotexist/repository/canve/simple-graph_2.11/0.0.1/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn] /repos/activator-1.3.2/repository/canve/simple-graph_2.11/0.0.1/ivys/ivy.xml
[warn] ==== public: tried
[warn] https://repo1.maven.org/maven2/canve/simple-graph_2.11/0.0.1/simple-graph_2.11-0.0.1.pom
[warn] ==== typesafe-releases: tried
[warn] http://repo.typesafe.com/typesafe/releases/canve/simple-graph_2.11/0.0.1/simple-graph_2.11-0.0.1.pom
[warn] ==== typesafe-ivy-releasez: tried
[warn] http://repo.typesafe.com/typesafe/ivy-releases/canve/simple-graph_2.11/0.0.1/ivys/ivy.xml
[warn] ==== sonatype-snapshots: tried
[warn] https://oss.sonatype.org/content/repositories/snapshots/canve/simple-graph_2.11/0.0.1/simple-graph_2.11-0.0.1.pom
[warn] ==== sonatype-releases: tried
[warn] https://oss.sonatype.org/content/repositories/releases/canve/simple-graph_2.11/0.0.1/simple-graph_2.11-0.0.1.pom
[info] Resolving canve#compiler-plugin-unit-test-lib_2.11;0.0.1 ...
[warn] module not found: canve#compiler-plugin-unit-test-lib_2.11;0.0.1
[warn] ==== local: tried
[warn] /home/matan/.ivy2/local/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/ivys/ivy.xml
[warn] ==== activator-launcher-local: tried
[warn] /doesnotexist/repository/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/ivys/ivy.xml
[warn] ==== activator-local: tried
[warn] /repos/activator-1.3.2/repository/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/ivys/ivy.xml
[warn] ==== public: tried
[warn] https://repo1.maven.org/maven2/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/compiler-plugin-unit-test-lib_2.11-0.0.1.pom
[warn] ==== typesafe-releases: tried
[warn] http://repo.typesafe.com/typesafe/releases/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/compiler-plugin-unit-test-lib_2.11-0.0.1.pom
[warn] ==== typesafe-ivy-releasez: tried
[warn] http://repo.typesafe.com/typesafe/ivy-releases/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/ivys/ivy.xml
[warn] ==== sonatype-snapshots: tried
[warn] https://oss.sonatype.org/content/repositories/snapshots/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/compiler-plugin-unit-test-lib_2.11-0.0.1.pom
[warn] ==== sonatype-releases: tried
[warn] https://oss.sonatype.org/content/repositories/releases/canve/compiler-plugin-unit-test-lib_2.11/0.0.1/compiler-plugin-unit-test-lib_2.11-0.0.1.pom
[info] Resolving jline#jline;2.12.1 ...
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: canve#simple-graph_2.11;0.0.1: not found
Sorry for the long paste.
Perry
@pfn
Oct 20 2015 15:10
scalaVersion probably does not match
i.e. you set scalaVersion in compilerPluginn but not in simpleGraph
matanster
@matanster
Oct 20 2015 15:11
Thanks, will check. And good to know it typically works for libraries - Indeed when I depart from having a library dependency, it just relies on the classpath and everything works.
Perry
@pfn
Oct 20 2015 15:13
canve#simple-graph_2.11;0.0.1: not found
that should be the hint right there
scalaVersion = 2.11.x in compilerPluginn, but either unset or something else in simpleGraph
should just jump straight to the error first, and the answer would be solved immediately
matanster
@matanster
Oct 20 2015 15:17

The error just means that adding the dependency didn't work, because of course there would be no artifact if this library is resolved without the the simpleGraph project first publishing its artifact.
They both contain the following:

scalaVersion := "2.11.7",
crossScalaVersions := Seq("2.10.4", "2.11.7"),

But I will suffice with removing the library dependencies (the alternative method for accomplishing the overall goal of having a master build that works).

Perry
@pfn
Oct 20 2015 15:18
huh?
no, dependsOn is internal ivy resolution
matanster
@matanster
Oct 20 2015 15:19
?
Perry
@pfn
Oct 20 2015 15:19
dependsOn internally adds a "libraryDependency" by default
you should not be specifying both dependsOn and a libraryDependency at the same time
matanster
@matanster
Oct 20 2015 15:22
How can dependsOn actually internally add a library dependency? does a library dependency resolve from the classpath before trying to fetch it from an ivy repo?
matanster
@matanster
Oct 20 2015 15:29
When I dependsOn, do the compilation artifacts of the dependency get internally tagged as a library, with the organization and version that are specified for the project?
Did you literally mean that
dependsOn internally adds a "libraryDependency" by default
?
Perry
@pfn
Oct 20 2015 15:45
sure
that's generally what it means
matanster
@matanster
Oct 20 2015 15:50
Thanks - good to know. Working on making my project hierarchy of plugins work without library dependency definitions now...
Richard Gomes
@frgomes
Oct 20 2015 16:15
I've provided a way to circumvent sbt/sbt#2247
See: https://github.com/frgomes/sbt-issue-2247
matanster
@matanster
Oct 20 2015 17:09
I'll byte my curiosity as to why this silently compiles but takes no effect:
update in compilerPluginn <<= (update in compilerPluginn).dependsOn(publishLocal in simpleGraph)
Perry
@pfn
Oct 20 2015 17:28
matanster, because the correct location is update in Compile
matanster
@matanster
Oct 20 2015 17:55
thanks! I might fallback to that if the current structuring I am pursuing goes awry (and so far it does, probably in my own fault though).
Perry
@pfn
Oct 20 2015 18:31
huh? do not fall back to mucking with update like that!
that's completely wrong
matanster
@matanster
Oct 20 2015 22:04
General question about sbt concurrency as it applies to logging: is there any way to get sbt logging per task? as I understand tasks that can run in parallel will just concurrently dump their messages to the log, making it hard to distinguish what's going on, in a complex multi-project build.