These are chat archives for sbt/sbt

27th
Dec 2016
Devon Stewart
@blast-hardcheese
Dec 27 2016 00:00
the ProjectRef not having been resolved during tut's compile phase. I'm currently reading through tutSettings to better understand what the world looks like
eugene yokota
@eed3si9n
Dec 27 2016 02:27
@ShaneDelmore I'm sure they are all mechanical, but it might depend on type etc
Devon Stewart
@blast-hardcheese
Dec 27 2016 02:31

I've made embarrassingly little progress on this issue. I've got a project generated by sbt-pom-reader, a Seq[ProjectRef], and I'm re-defining the root project as:

lazy val root =
  project.in(file("."))
    .dependsOn(tutProjects map { _ % "test->test;compile->compile" }: _*)

. Without the map, the types don't match up (but with a little fumbling I can find an implicit that gets me to something consumable by dependsOn). With the map, everything compiles and tut runs successfully, but test doesn't trigger on subprojects.

sbt-pom-reader defines the root project as an AggregateProject if there are modules in the pom, which is almost the right thing, but since my documentation requires imports from the different subprojects, I need dependsOn, not just aggregates
the question is, given that definition of root above, and the fact that I'm re-defining a project that is already provided by sbt-pom-reader, why doesn't test trigger test on all dependsOn projects?
I'm missing something fundamental to SBT, I think
Devon Stewart
@blast-hardcheese
Dec 27 2016 02:37
:\ when I add aggregate(tutProjects: _*) test works again
nafg
@nafg
Dec 27 2016 02:38
FTR is there a reason you're using such old docs?
Devon Stewart
@blast-hardcheese
Dec 27 2016 02:39
thanks for calling that out though, I noticed it but hadn't given it any thought -- figured if something drastic had changed I'd have gotten a compiler error.
nafg
@nafg
Dec 27 2016 02:40
certainly one hopes ;)
Devon Stewart
@blast-hardcheese
Dec 27 2016 02:41

so,

lazy val root =
  project.in(file("."))
    .dependsOn(tutProjects map { _ % "test->test;compile->compile" }: _*)
    .aggregate(tutProjects: _*)

is what I've got now, and that works

although the documentation suggests I shouldn't need the .aggregate(...)
(more importantly, since I'm redefining root, I'm only testing packages that I've explicitly listed. If anyone adds more modules to the pom.xml, they will not be included here.)
nafg
@nafg
Dec 27 2016 02:46
@blast-hardcheese aggregate is orthogonal
Without the map, the types don't match up
Can you be more specific?
Devon Stewart
@blast-hardcheese
Dec 27 2016 02:47
yes, one second
 found   : Seq[sbt.ProjectRef]
 required: Seq[sbt.ClasspathDep[sbt.ProjectReference]]
    .dependsOn(subprojects: _*)
               ^
sbt.compiler.EvalException: Type error in expression
dependsOn(db, ...) works, this seems to just be a product of having these in a Seq[ProjectRef]
so by adding a configuration to the ProjectRef it gives the types a chance to coalesce into something compatible
So. With .aggregate(...), my tests run. Deleting aggregate(...), reload, test, my tests do not run.
@nafg ^^
that is the only thing that has changed.
(using sbt 0.13.13, sbt-pom-reader 2.0.0)
nafg
@nafg
Dec 27 2016 03:03
@blast-hardcheese ok I thought .aggregate made the build file compile
@blast-hardcheese aggregate means that you can run command X in project A and it will run B/X for you as well
So without it you'd have to run db/test instead
Devon Stewart
@blast-hardcheese
Dec 27 2016 03:15
oh, then that's exactly what I wanted.
hmm.
nafg
@nafg
Dec 27 2016 04:13
@blast-hardcheese yeah sorry I misunderstood before, but all I said is it's orthogonal to the type error
Devon Stewart
@blast-hardcheese
Dec 27 2016 04:16
gotcha -- I thought you meant it was orthogonal to the problem I was having :)
thank you for clarifying
nafg
@nafg
Dec 27 2016 04:19
yeah I didn't realize there were 2 problems
Ólafur Páll Geirsson
@olafurpg
Dec 27 2016 13:21
FWIW I just opened two feature request to improve quality-of-life for sbt plugin authors, see sbt/sbt#2880 and sbt/sbt#2879 Maybe someone here has bumped into similar issues and might want to pitch in.
Grzegorz Slowikowski
@gslowikowski
Dec 27 2016 14:29
Hi. On 22 Nov I asked for publishing SBT 0.13.13 scaladocs. @dwijnand answered that there is a bug in scaladoc blocking it. Can this be done now (with latest Scala 2.12.1, there was scaladoc bug fixed - I don't know if this is it)?
OlegYch
@OlegYch
Dec 27 2016 14:30
sbt 0.13 is using scala 2.10..
Grzegorz Slowikowski
@gslowikowski
Dec 27 2016 14:48
So I don't know, what was the problem. Anyway, can you publish scaladoc for 0.13.13 (http://www.scala-sbt.org/0.13.13/api/)?
Brian Topping
@briantopping
Dec 27 2016 15:36
Does anyone know how to use “Tasks Activation” in IntelliJ? I’d like to be able to add SBT tasks I use a lot to the GUI so I can run them from there.
Brian Topping
@briantopping
Dec 27 2016 15:42
Mostly because changing directories and running SBT from the command line is more steps than a few clicks and it adds up with five isolated SBT projects that aren’t children of each other.
Erik LaBianca
@easel
Dec 27 2016 17:35
@briantopping I can’t figure out what that thing is supposed to be for. It would be great if I could click a thing and have it run sbt compile with clickable error messages but thats apparently not what it does =p
Brian Topping
@briantopping
Dec 27 2016 17:35
Hah, I know!
I can’t figure out what it does at all except take up screen real estate and allow you to reload certain projects (instead of all projects). Which makes me think I’m hitting a fundamental bug and that so few people use it, nobody has reported it.
OlegYch
@OlegYch
Dec 27 2016 17:46
i don't think it's implemented
though latest builds provide access to sbt shell directly, so you won't need that
better ask on #JetBrains/intellij-scala
Brian Topping
@briantopping
Dec 27 2016 18:00
Thanks for the reference, @OlegYch! Perfect...
Brian Topping
@briantopping
Dec 27 2016 19:07

Ok, I think after four years, I am finally starting to understand SBT for more than a day, but have a question that should be easy and hopefully connects a lot of concepts: I changed the artifact types that are being generated under sbt-osgi from bundle back to jar using this:

    Keys.artifact in(Compile, Keys.packageBin) ~= (_.copy(`type` = "jar")),

While publishM2 and publishLocal still seem to work, publish to a nexus repository seems to have stopped working. I get a POM that is pushed via publishMavenStyle := true, but none of the artifacts.

What I am interested in is how to use inspect tree to find why.
I did an inspect tree publish and understand most of it, but I’m trying to learn the tricks to zeroing in on relevant information when one doesn’t exactly know what they are looking for
does that make sense?
Brian Topping
@briantopping
Dec 27 2016 19:15
When I would get stuck in these situations in Maven, one could dump the plugin and since the metadata was stored, the dump was always available. In SBT, keys fill that role, but I feel like I am missing something about searching them in a global project.
Kind of like if there was a way to free-text search of the description fields of a given build
Not that I think that would be a magic bullet, just that it might be something
It does seem that SBT needs to be a part of the Scala Specialization on Coursera. I will start lobbying people for that.
OlegYch
@OlegYch
Dec 27 2016 19:26
you could start by diffing publishLocal and publish trees..
i usually just look in the code
Brian Topping
@briantopping
Dec 27 2016 19:26
It just doesn’t make sense that someone might be considered a Scala expert without being able to read @eed3si9n’s SBT in 4 dimensions article and understand it on first read. He calls that “intermediate level reading”, so there shouldn’t be any excuse that someone with a Scala Specialization on their LinkedIn doesn’t understand it, right?
@OlegYch that’s a really good idea, that’s exactly the kind of tip I was hoping to find here :D
I’ve also been looking in the code, but I think my issues are in configuration and not behavior
Brian Topping
@briantopping
Dec 27 2016 20:01
@OlegYch the tree comparisons are the same (excepting the root task differences and additional settings for publushMavenStyle and publishTo.
Brian Topping
@briantopping
Dec 27 2016 20:14
Ok, so maybe this was never a problem to begin with. SBT was reporting that the artifact was not on Nexus, which when looking at the URL that it was searching in, it was not. But the maven-metadata.xml file was there, and I forgot that it referenced other directories.
SBT, for it’s part, appears to be either looking in the wrong directory for the jar or is not publishing it to the correct directory so that it can be found.
I created sbt/sbt#2873 a week ago and it was summarily shot in the head without a trial, and I bet they are related.
I really hate wasting time like this. Time is the only thing we have in the world.
OlegYch
@OlegYch
Dec 27 2016 20:26
looks like both eugene and osgi folks argue against using unversioned snapshots at all?
Brian Topping
@briantopping
Dec 27 2016 21:04
Yah I don’t really know, I was hoping to discover that in the issue and was fine to let it go in the moment, just assuming that if the issue was so unimportant, it would not cause future problems.
Brian Topping
@briantopping
Dec 27 2016 21:09
I guess the magic of build.properties is you can build your own version, push it to Nexus and move along
OlegYch
@OlegYch
Dec 27 2016 21:42
you mean build your own version of sbt?
Brian Topping
@briantopping
Dec 27 2016 21:43
yes, since I still have no understanding of the impact of #2873. I was just trying to triage it there and well, it doesn’t work anyway.
That said, I haven’t put in as much time yet as the collective writers of this thread, so I guess I am still ahead of the game: https://groups.google.com/forum/?fromgroups#!topic/scala-internals/Xtm3-TciwNg
Brian Topping
@briantopping
Dec 27 2016 21:55
@OlegYch So I just discovered that a version of the form 0.1.0.SNAPSHOT causes the deployer to push with a format that is called “timed snapshots”. For reference, in Maven, this is disabled with uniqueVersion=false.
I did not dig deeply, but either they are being deployed improperly or they are being read improperly