How to set a system property in build.sbt?

[Tommy Li]

How do I pass a system property to my program when I use "run" within
build.sbt?

I looked around and tried something like:

systemProperties += "java.library.path"->"/opt/lwjgl-2.8.3/native/
linux"

but it does not seem to work...

[Kristian Domagala]

I'm not sure how to do it in a .sbt file, but two other options are,
1. add it to your project/Build.scala file (System.setProperty(...)), or
2. pass it as a parameter to your launch script, eg,
  $> sbt -Djava.library.path=/opt/lwjgl-2.8.3/native/linux run

Cheers,
Kristian.

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
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.

[Sciss]

without testing, i think it is something like

javaOptions += "-Dkey=value"

(maybe javaOptions in Runtime ?)

[Mark Harrah]

On Fri, 3 Feb 2012 09:08:16 +1000
Kristian Domagala <kristian...@gmail.com> wrote:

> I'm not sure how to do it in a .sbt file, but two other options are,
> 1. add it to your project/Build.scala file (System.setProperty(...)), or
> 2. pass it as a parameter to your launch script, eg,
> $> sbt -Djava.library.path=/opt/lwjgl-2.8.3/native/linux run

Right. To answer your question about how to do it in a .sbt file, you can use the 'initialize' setting (of type Unit) to run code when a project is loaded.

// important to use ~= so that any other initializations aren't dropped
// the _ discards the meaningless () value previously assigned to 'initialize'
initialize ~= { _ =>
System.setProperty(...)
}

-Mark

Extra details: initialize isn't used anywhere in sbt other than to provide the boring global default of 'initialize := ()'. However, all settings are evaluated at project load exactly once, so the code for 'initialize' is run once at load time. You could also do:

SettingKey[Unit]("my-initialization") := {
<your code here>
}

Strictly speaking, this code and the code for "initializing" initialize is run when settings are evaluated, whereas the code for in a project/Build.scala file would run when the Build object is created (which is before settings are evaluated)

[Mark Harrah]

On Fri, 3 Feb 2012 00:03:29 +0000
Sciss <con...@sciss.de> wrote:

> without testing, i think it is something like
>
> javaOptions += "-Dkey=value"
>
> (maybe javaOptions in Runtime ?)

This only works if you fork 'run', but otherwise yes, that is the correct setting. 'in Runtime' is probably better because it is more specific.

-Mark

[Mark Harrah]

On Mon, 30 Jan 2012 17:47:13 -0800 (PST)
Tommy Li <tomm...@ucla.edu> wrote:

> How do I pass a system property to my program when I use "run" within
> build.sbt?
>
> I looked around and tried something like:
>
> systemProperties += "java.library.path"->"/opt/lwjgl-2.8.3/native/
> linux"

If you just want to make native libraries available to your application and you don't fork 'run', you can put them on the classpath. The simplest way is to put them in lib/ or put a symlink in lib/, but you can also add them directly to unmanagedJars. This approach allows sbt to properly handle multiple runs without needing to fork. (It avoids the LinkageError that you would get from loading the same native library twice. If you fork, it doesn't do anything.)

-Mark

[fmpwizard]

I have a related question.

While running tests on my application, I wanted to set the property
run.mode=test . But during normal development I wanted the run.mode to
be empty or not specified.

I added this to build.sbt

testOptions in Test += Tests.Setup( () =>
System.setProperty("run.mode", "test"))

but what I notice is that if I:

1- start sbt
2- run some unit test
3- on the same session, after the tests are run, I do:
4- container:start
5- It seems that run.mode is still test

Are my assumptions correct and if so, how can I correct it?

Thanks

Diego

On Feb 2, 10:30 pm, Mark Harrah <dmhar...@gmail.com> wrote:
> On Mon, 30 Jan 2012 17:47:13 -0800 (PST)
>

[Mark Harrah]

Hi Diego,

On Thu, 2 Feb 2012 21:27:08 -0800 (PST)
fmpwizard <fmpw...@gmail.com> wrote:

> I have a related question.
>
> While running tests on my application, I wanted to set the property
> run.mode=test . But during normal development I wanted the run.mode to
> be empty or not specified.
>
> I added this to build.sbt
>
> testOptions in Test += Tests.Setup( () =>
> System.setProperty("run.mode", "test"))
>
> but what I notice is that if I:
>
> 1- start sbt
> 2- run some unit test
> 3- on the same session, after the tests are run, I do:
> 4- container:start
> 5- It seems that run.mode is still test
>
> Are my assumptions correct and if so, how can I correct it?

Tests are run in the same jvm (otherwise, setting the system property like you do wouldn't have any effect). You'd need to unset the system property after running tests.

In general, system properties should be avoidable if possible. Test frameworks like ScalaTest usually provide ways to provide information to your tests in a more reliable way.

-Mark

[Diego Medina]

Diego
Sent from my android cell

On Feb 7, 2012 10:00 AM, "Mark Harrah" <dmha...@gmail.com> wrote:
>
> Hi Diego,
>
> On Thu, 2 Feb 2012 21:27:08 -0800 (PST)
> fmpwizard <fmpw...@gmail.com> wrote:
>
> > I have a related question.
> >
> > While running tests on my application, I wanted to set the property
> > run.mode=test . But during normal development I wanted the run.mode to
> > be empty or not specified.
> >
> > I added this to build.sbt
> >
> > testOptions in Test += Tests.Setup( () =>
> > System.setProperty("run.mode", "test"))
> >
> > but what I notice is that if I:
> >
> > 1- start sbt
> > 2- run some unit test
> > 3- on the same session, after the tests are run, I do:
> > 4- container:start
> > 5- It seems that run.mode is still test
> >
> > Are my assumptions correct and if so, how can I correct it?
>
> Tests are run in the same jvm (otherwise, setting the system property like you do wouldn't have any effect).  You'd need to unset the system property after running tests.
>
> In general, system properties should be avoidable if possible.  Test frameworks like ScalaTest usually provide ways to provide information to your tests in a more reliable way.

Thanks Mark

>
> -Mark
>
> > Thanks
> >
> >   Diego
> >
> >
> > On Feb 2, 10:30 pm, Mark Harrah <dmhar...@gmail.com> wrote:
> > > On Mon, 30 Jan 2012 17:47:13 -0800 (PST)
> > >
> > > Tommy Li <tommy...@ucla.edu> wrote:
> > > > How do I pass a system property to my program when I use "run" within
> > > > build.sbt?
> > >
> > > > I looked around and tried something like:
> > >
> > > > systemProperties += "java.library.path"->"/opt/lwjgl-2.8.3/native/
> > > > linux"
> > >
> > > If you just want to make native libraries available to your application and you don't fork 'run', you can put them on the classpath.  The simplest way is to put them in lib/ or put a symlink in lib/, but you can also add them directly to unmanagedJars.  This approach allows sbt to properly handle multiple runs without needing to fork.  (It avoids the LinkageError that you would get from loading the same native library twice.  If you fork, it doesn't do anything.)
> > >
> > > -Mark
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > but it does not seem to work...
> >
>