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

export classpath no longer exports #1155

Closed
paulp opened this issue Mar 7, 2014 · 8 comments
Closed

export classpath no longer exports #1155

paulp opened this issue Mar 7, 2014 · 8 comments
Labels
Milestone

Comments

@paulp
Copy link
Contributor

paulp commented Mar 7, 2014

In 0.13.1, given this build.sbt

scalaVersion := "2.11.0-RC1"

libraryDependencies += "org.scala-lang" % "scala-reflect" % scalaVersion.value

Running sbt 'export fullClasspath' gives this:

/Users/paulp/scratch/2014-03-07_scala_1/target/scala-2.11.0-RC1/classes:/Users/paulp/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.11.0-RC1.jar:/Users/paulp/.ivy2/cache/org.scala-lang/scala-reflect/jars/scala-reflect-2.11.0-RC1.jar

In 0.13.2-M1 and -M2, it just exits silently.

@jsuereth jsuereth added this to the 0.13.2 milestone Mar 7, 2014
@jsuereth jsuereth added the Bug label Mar 7, 2014
@jsuereth
Copy link
Member

jsuereth commented Mar 7, 2014

This appears to be related to the addition of the all task. Somewhere along the chain our "show values" settings. Specifically, this line looks suspicious: https://github.com/sbt/sbt/blob/0.13/main/src/main/scala/sbt/Aggregation.scala#L157

I'm still investigating, this is just a note so I don't forget.

@jsuereth
Copy link
Member

jsuereth commented Mar 7, 2014

Hmm, was barking up the wrong tree. This commit is interesting: ca7e78d.

@jsuereth
Copy link
Member

jsuereth commented Mar 7, 2014

It looks like we have more than one "export" stream per task run. That commit ensures the one we read from is closed before written to, although there is another file which DOES have the correct value in it. Going to figure out how to wire up to the correct export stream, then we should be good to go.

@jsuereth
Copy link
Member

jsuereth commented Mar 7, 2014

Ok, the issue appears to be we're exporting things with the 'streams' key (associated with the fullClaspsath task), but we're reading from the 'fullClasspath' key, so the resulting stream is empty.

[SUCKY DEBUG] Exporting: Stream(ScopedKey(Scope(Select(ProjectRef(file:/home/jsuereth/projects/sbt/test-ivy-issues/,test-ivy-issues)),Select(ConfigKey(compile)),Select(fullClasspath),Global),streams), export, @/home/jsuereth/projects/sbt/test-ivy-issues/target/streams/compile/fullClasspath/$global/streams/export)
[SUCKY DEBUG] Reading  : Stream(ScopedKey(Scope(Select(ProjectRef(file:/home/jsuereth/projects/sbt/test-ivy-issues/,test-ivy-issues)),Select(ConfigKey(compile)),Select(fullClasspath),Global),fullClasspath), export, @/home/jsuereth/projects/sbt/test-ivy-issues/target/streams/compile/fullClasspath/$global/fullClasspath/export)

Lining up the keys in that way shows exactly the issue.

jsuereth added a commit that referenced this issue Mar 7, 2014
Fixes #1155.

It seems that somehow during the 0.13.{1 -> 2 } transition, we
stopped pointing at the correct key for TaskKeys (either that or
task streams are now all associated with the `streams` key).  I
think this may have been inadvertently caused from several
refactorings to enable greater control over the execution of tasks.

This points the `last*` methods at the correct key for tasks,
fixing both `last <key>` and `export <key>` commands.
@jsuereth
Copy link
Member

jsuereth commented Mar 7, 2014

Found it. Will be fixed in the RC1.

@paulp
Copy link
Contributor Author

paulp commented Mar 7, 2014

Great, thanks.

@paulp
Copy link
Contributor Author

paulp commented Mar 7, 2014

Oh yeah - I saw there was a test which issued some command involving export classpath, and it has apparently not been failing. That might merit investigation in case it's not testing what it was written to test.

@jsuereth
Copy link
Member

jsuereth commented Mar 7, 2014

Yeah, it was never testing what made it to System.out from the sbt process. We actually don't have hooks for those tests, so unfortunately the only way to test export right now is to reimplement its logic in a test, which is mostly a useless exercise in CPU.

I'll be working the test suite slowly over the coming months for greater stability + a few more features so we can check things like "export". Ironically, the move to sbt-server makes checking System.out easy and a lot else harder.

jsuereth added a commit that referenced this issue Mar 8, 2014
Fixes #1155.

It seems that somehow during the 0.13.{1 -> 2 } transition, we
stopped pointing at the correct key for TaskKeys (either that or
task streams are now all associated with the `streams` key).  I
think this may have been inadvertently caused from several
refactorings to enable greater control over the execution of tasks.

This points the `last*` methods at the correct key for tasks,
fixing both `last <key>` and `export <key>` commands.
jsuereth added a commit to eed3si9n/sbt that referenced this issue Mar 21, 2014
Fixes sbt#1155.

It seems that somehow during the 0.13.{1 -> 2 } transition, we
stopped pointing at the correct key for TaskKeys (either that or
task streams are now all associated with the `streams` key).  I
think this may have been inadvertently caused from several
refactorings to enable greater control over the execution of tasks.

This points the `last*` methods at the correct key for tasks,
fixing both `last <key>` and `export <key>` commands.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 4, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants