Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some keys get silently dropped from output #125

Open
ryan-williams opened this issue Apr 22, 2018 · 4 comments
Open

Some keys get silently dropped from output #125

ryan-williams opened this issue Apr 22, 2018 · 4 comments

Comments

@ryan-williams
Copy link

The example from the README works for me:

BuildInfoKey.map(name) { case (k, v) => "project" + k.capitalize -> v.capitalize }

but if I try e.g.:

BuildInfoKey.map(moduleID) { case (k, v)  "projectMod" -> v.name }

I get no errors or warnings, but there is no projectMod key/value in the output.

Why might this be?

@dwijnand
Copy link
Member

what version? for example, is this a regression in 0.9.0?

@ryan-williams
Copy link
Author

Sorry, I believe I just observed this with 0.8.0 and 0.9.0.

One theory I have is that something is "wrong" with moduleID as a settingKey; I can't enter it in the SBT repl, for reasons unknown to me:

sbt:lib> projectID
[info] lib:lib:0.1.0-SNAPSHOT
sbt:lib> moduleID
[error] Not a valid command: moduleID
[error] Not a valid project ID: moduleID
[error] Expected ':'
[error] Not a valid key: moduleID (similar: moduleName, moduleGraph, ivyModule)
[error] moduleID
[error]         ^

Still, if some keys are indeed "off-limits", buildinfo shouldn't just silently fail.

Any context about any of this is appreciated.

I can try to make a smaller repro case if it really isn't expected that things like this would ever happen; I somewhat expected the answer to be that there is something about how BuildInfo gets keys and values, or intrinsic differences between keys, that would explain this behavior.

@dwijnand
Copy link
Member

One theory I have is that something is "wrong" with moduleID as a settingKey; I can't enter it in the SBT repl, for reasons unknown to me

yes, looks like moduleID is unset in general, and set in specific places:

but it's constructed (see the first 2 instances) from projectID, so you should be able to use that.

Still, if some keys are indeed "off-limits", buildinfo shouldn't just silently fail.

agreed. clearly.

Any context about any of this is appreciated.

I can try to make a smaller repro case if it really isn't expected that things like this would ever happen; I somewhat expected the answer to be that there is something about how BuildInfo gets keys and values, or intrinsic differences between keys, that would explain this behavior.

hopefully that give some context and explains some of the behaviour.

@frgomes
Copy link

frgomes commented Oct 3, 2018

I've configured SBT like this:

def thisProject(scope: Scope): Scope = Scope.subThisProject(scope)
def buildinfoSettings(scope: Scope): Seq[Setting[_]] =
  Seq(
    buildInfoPackage in thisProject(scope) := "build",
    buildInfoKeys    in thisProject(scope) :=
      Seq[BuildInfoKey](
        organization        in thisProject(scope),
        name                in thisProject(scope),
        version             in thisProject(scope),
        scalaVersion        in thisProject(scope),
        sbtVersion          in thisProject(scope),
        baseDirectory       in thisProject(scope),
        resourceDirectory   in thisProject(scope),
        resourceDirectories in thisProject(scope),
        sourceManaged       in thisProject(scope),
        resourceManaged     in thisProject(scope),
      ))

and I've got BuildInfo.scala like this below, which misses keys resourceDirectory and resourceDirectories:

package build

import scala.Predef._

/** This object was generated by sbt-buildinfo. */
case object BuildInfo {
  /** The value is "company". */
  val organization: String = "company"
  /** The value is "proj-core". */
  val name: String = "proj-core"
  /** The value is "0.1.0-SNAPSHOT". */
  val version: String = "0.1.0-SNAPSHOT"
  /** The value is "2.12.7". */
  val scalaVersion: String = "2.12.7"
  /** The value is "1.2.3". */
  val sbtVersion: String = "1.2.3"
  /** The value is new java.io.File("/home/rgomes/workspace/proj/proj-core"). */
  val baseDirectory: java.io.File = new java.io.File("/home/rgomes/workspace/proj/proj-core"),
  /** The value is new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/src_managed"). */
  val sourceManaged: java.io.File = new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/src_managed")
  /** The value is new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/resource_managed"). */
  val resourceManaged: java.io.File = new java.io.File("/home/rgomes/workspace/proj/proj-core/target/scala-2.12/resource_managed")
  override val toString: String = {
    "organization: %s, name: %s, version: %s, scalaVersion: %s, sbtVersion: %s, sourceManaged: %s, resourceManaged: %s" format (
      organization, name, version, scalaVersion, sbtVersion, sourceManaged, resourceManaged
    )
  }
}

I've double checked to see whether my submodule proj-core contains the missing keys. Yes. it does:

sbt:proj> show proj-core/resourceDirectory
[info] /home/rgomes/workspace/proj/proj-core/src/main/resources
sbt:proj> show proj-core/resourceDirectories
[info] * /home/rgomes/workspace/proj/proj-core/src/main/resources
[info] * /home/rgomes/workspace/proj/proj-core/target/scala-2.12/resource_managed/main

I've tested with:

  • SBT version 1.2.3
  • sbt-buildinfo versions 0.7.0, 0.8.0 and 0.9.0
    I was initiallly using version 0.7.0 but I've observed the very same behavior on versions 0.8.0 and 0.9.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants