How to use different javaOptions in different configurations?

[Sebastian]

I'm using sbt 0.12.1. In my project I've two different configurations Test and IntTest. The javaOptions of IntTest doesn't get applied when I run int:test. The value for prop is always val1. 

When I inspect the prop with:

  show int:test:java-options

I get the correct value:

  [info] List(-Dprop=val2)

Here is my project definition:

  lazy val testProj = Project(

id = "test",  

base = file("test"), 

settings = Seq(

    organization := buildOrganization,

   version := buildVersion,

   fork in Test := true,

   testOptions in Test := Seq(

    Tests.Filter(s => s.endsWith("Test") && !(s.endsWith("IntTest") || s.endsWith("SystemTest")))

   ),

   parallelExecution in Test := false,

   javaOptions in Test := Seq(

    "-Dprop=val1"

   ),

   javaOptions in IntTest := Seq(

     "-Dprop=val2"

   )

   ) ++ standardSettings ++ testPrepDependencies

)

.configs(IntTest)

.settings(inConfig(IntTest)(Defaults.testTasks) : _*)

Any ideas what's wrong?

[Mark Harrah]

It looks like the intermediate settings problem[#391], which hopefully will be addressed in 0.13. The workaround would be to add the intermediate setting to the IntTest scope:

inConfig(IntTest)(Seq(
testGrouping <<= singleTestGroup(test)
))

You should be able to append the Seq(testGrouping <<= ...) to Defaults.testTasks in the last line of your example.

-Mark

[#391]: https://github.com/sbt/sbt/issues/391

> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/E_O6lNC9zcwJ.
> To post to this group, send email to simple-b...@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>

[Richard Johnson]

Has this been fixed in 0.13?

I am trying to create a "debug" testing configuration using 0.13.0-RC3 but it doesn't use the specified javaOptions when running "debug:test". I followed the instructions in http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Testing.html that describe adding a configuration to control testing.  Here's a test project SBT file:

lazy val TopProj = Project(id = "Top", base = file(".")).configs(TestDebug)

lazy val TestDebug = config("debug") extend Test

// Change the configuration from "TestDebug" to "Test" and it will work - for all testing...
inConfig(TestDebug)(Seq(
    fork in ThisBuild := true,
    javaOptions in ThisBuild ++= Seq(
        "-Xdebug", "-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005",
        "-Xms512M", "-Xmx1200M", "-Xss1M", "-XX:MaxPermSize=384M" )
))
   
libraryDependencies in ThisBuild ++= Seq(
  "org.specs2" %% "specs2" % "2.1" % "test" withSources() withJavadoc()
)

Make sure you add a valid test source file in "src/test/scala" so that testing actually starts the JVM. As I'm sure that you're aware, this will start the JVM and immediately suspend it waiting for a debugger to attach to the process.

Running either "test" or "debug:test" runs the test without suspending. If I change the "inConfig(TestDebug)" to "inConfig(Test)" running either "test" or "debug:test" suspends and works as expected. However, this isn't a usable solution since all test execution now suspends. I plan on using "debug:testOnly aFailingTest" to run failing tests in the debugger. 

BTW, the new features in 0.13 are great.

Rich

[Mark Harrah]

Hi Rich,

On Mon, 22 Jul 2013 17:31:01 -0700 (PDT)
Richard Johnson <rjoh...@goaldesigns.com> wrote:

> Has this been fixed in 0.13?
>
> I am trying to create a "debug" testing configuration using 0.13.0-RC3 but
> it doesn't use the specified javaOptions when running "debug:test". I
> followed the instructions in
> http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Testing.html that
> describe adding a configuration to control testing. Here's a test project
> SBT file:
>
> lazy val TopProj = Project(id = "Top", base = file(".")).configs(TestDebug)
>
> lazy val TestDebug = config("debug") extend Test
>
> // Change the configuration from "TestDebug" to "Test" and it will work -
> for all testing...
> inConfig(TestDebug)(Seq(
> fork in ThisBuild := true,
> javaOptions in ThisBuild ++= Seq(
> "-Xdebug",
> "-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005",
> "-Xms512M", "-Xmx1200M", "-Xss1M", "-XX:MaxPermSize=384M" )
> ))
>
> libraryDependencies in ThisBuild ++= Seq(
> "org.specs2" %% "specs2" % "2.1" % "test" withSources() withJavadoc()
> )

(Side note: the updateClassifiers task is recommended. withSources/withJavadoc was mainly used before updateClassifiers existed. IDE integration in particular will handle this automatically.)

> Make sure you add a valid test source file in "src/test/scala" so that
> testing actually starts the JVM. As I'm sure that you're aware, this will
> start the JVM and immediately suspend it waiting for a debugger to attach
> to the process.
>
> Running either "test" or "debug:test" runs the test without suspending. If
> I change the "inConfig(TestDebug)" to "inConfig(Test)" running either
> "test" or "debug:test" suspends and works as expected. However, this isn't
> a usable solution since all test execution now suspends. I plan on using
> "debug:testOnly aFailingTest" to run failing tests in the debugger.

The missing piece from the Testing page is putting:

inConfig(TestDebug)( Defaults.testTasks )

before the other settings (if following the shared sources section). This adds the actual test tasks to that configuration. Otherwise, debug:test is just delegating to test:test.

You can verify this with `inspect debug:test` and looking at Provided By. You can also see that the debug settings are unused with `inspect debug:javaOptions` and seeing no reverse dependencies. Then, look at `inspect test:javaOptions` and see that it gets used by testGrouping.

(I've thought about not delegating from the command line to avoid this confusion, but I'm not sure of the side effects yet.)

> BTW, the new features in 0.13 are great.

Thanks for the feedback!

-Mark

> Rich

>
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to simple-build-t...@googlegroups.com.

> To post to this group, send email to simple-b...@googlegroups.com.

> Visit this group at http://groups.google.com/group/simple-build-tool.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Richard Johnson]

Thanks Mark,

Yes it works now. Adding "inConfig(TestDebug)( Defaults.testTasks )" to my above build sample makes testing tasks in the debug configuration use the javaOptions with debug settings (as I had wanted). I was then able to get this working in my project's build by applying these settings to the "server" subproject. It seems that I was struggling with issues in both the multi-project settings and the configuration settings.

Your hints about using the inspect command are appreciated. I "show"ed that the "debug:javaOptions" were correctly set but didn't catch that they weren't be referenced (i.e. reverse dependencies).

Also I appreciate your side not about updateClassifiers. We use sbt-idea to generate our IntelliJ project so it appears we're covered without specifying withSources/withJavadoc. It's too easy on the web to find old or wrong advice. For exampIe, just now I searched for "updateClassifiers" and found this recent blog post (http://www.plotprojects.com/create-an-intellij-idea-project-with-library-sources-attached/) that states that you need to manually invoke updateClassifiers before gen-idea and then suggests making a command alias...

SBT 0.13 is working great for our build which is still mostly using 0.12 features. When I first started using SBT a few years ago, I struggled with creating my own custom setting and then using that value in an .sbt file. Now this can be done in an .sbt file with the new vals and defs along with the value method. For all of the depth that SBT has - it's these simple things that make a big difference. 

Thanks again,

Rich

[Mark Harrah]

On Wed, 24 Jul 2013 02:15:59 -0700 (PDT)
Richard Johnson <rjoh...@goaldesigns.com> wrote:

> Thanks Mark,
>
> Yes it works now. Adding "inConfig(TestDebug)( Defaults.testTasks )" to my
> above build sample makes testing tasks in the debug configuration use the
> javaOptions with debug settings (as I had wanted). I was then able to get
> this working in my project's build by applying these settings to the
> "server" subproject. It seems that I was struggling with issues in both the
> multi-project settings and the configuration settings.

Ok, great. If you have comments on how to explain this better given in the docs the changes in 0.13, I'm open to suggestions. I hope to go through the docs again for 0.13.1.

> Your hints about using the inspect command are appreciated. I "show"ed that
> the "debug:javaOptions" were correctly set but didn't catch that they
> weren't be referenced (i.e. reverse dependencies).
>
> Also I appreciate your side not about updateClassifiers. We use sbt-idea to
> generate our IntelliJ project so it appears we're covered without
> specifying withSources/withJavadoc. It's too easy on the web to find old or
> wrong advice. For exampIe, just now I searched for "updateClassifiers" and
> found this recent blog post (
> http://www.plotprojects.com/create-an-intellij-idea-project-with-library-sources-attached/)
> that states that you need to manually invoke updateClassifiers before
> gen-idea and then suggests making a command alias...

That is odd. It is a relatively recent post as well. I'd be surprised if running update-classifiers explicitly was ever necessary, but I suspect it fixed something for the author at some point. Sometimes the commands for IDE plugins (like sbt-idea) expect something like with-sources=true (or maybe that is/was just sbteclipse).

> SBT 0.13 is working great for our build which is still mostly using 0.12
> features. When I first started using SBT a few years ago, I struggled with
> creating my own custom setting and then using that value in an .sbt file.
> Now this can be done in an .sbt file with the new vals and defs along with
> the value method. For all of the depth that SBT has - it's these simple
> things that make a big difference.

Thanks for elaborating. It is good to hear how these changes improved things. Further suggestions for improvements are also appreciated.

-Mark

> Thanks again,