Allow to inject some configuration from the Build file to the application in DEV mode

[guillaumebort]

As reported in https://play.lighthouseapp.com/projects/82401-play-20/tickets/794-for-discussion-expose-a-new-way-to-get-settings-from-the-build-system-to-a-running-play-app#ticket-794-2, using global Java system properties to override some settings is painful with multi-projects organization.

Let's introduce a new Build setting devSettings: Seq[(String, String)] to inject some configuration into the Play application at Dev time. These values are seen as standard configuration values.

Here is the priority order:

• A global Java system property always override any value set in application.conf
• A value injected via devSettings always override both, the value set in application.conf or set via a global Java system property.

The special setting config.file can be used to specify another main application configuration file (the same way the global -Dconfig.file=xxx does it currently).

Here is a sample:

val main = play.Project(appName, appVersion, appDependencies).settings(

  , devSettings +=  ("config.file" -> "conf/my.conf")
  , devSettings +=  ("application.context" -> "/youhou")
  , devSettings +=  ("application.version" -> appVersion)
  , devSettings <+= (baseDirectory) { root => "application.root" -> root.getAbsolutePath }

)

[brikis98]

Nice, thank you.

A question: should the setting values be limited to String? The typesafe config library supports lists, maps, booleans, numbers, etc that may be useful.

[pk11]

LGTM.

I consider this feature as an extension of the System#getProperty idea, so personally I think supporting Seq[(String, String)] is sufficient.

just my 2c.

[jroper]

LGTM. I agree with Peter, this is a mechanism for supplying system properties in dev.

[brikis98]

Fair enough. Ship it 👍

[guillaumebort]

@brikis98 Actually it would be a bit diffcult to allow more complex Scala types here. Because the build and the runtime can use different version of Scala (For Play 2.1, the build still use Scala 2.9.2 while the runtime uses Scala 2.10), we can't share any Scala value via the SbtLink.

If we need something more complex than simple String, we will have to rely on Java only values.

[brikis98]

@guillaumebort If the build is still on scala 2.9.2 while the runtime is on 2.10, does that mean you can't share any code between the build and the runtime code? For example, we have a library that's used both in our sbt build code and in our runtime code. If that library was written in Scala, would we have to cross compile it to share it??

[guillaumebort]

@brikis98 Yes. Java libraries can be shared as is, but Scala libraries must be cross-compiled.

[brikis98]

@guillaumebort ouch. Any plans to move the build to 2.10 soon? :)

[guillaumebort]

As soon as there is a version of sbt compiled itself for Scala 2.10 it will be possible. But we will probably release Play 2.1 before that.

[jroper]

Though, while we will be upgrading to Scala 2.10 for builds when SBT supports it, I assume we'll still be maintaining the sbt link and not sharing code between them, so that we aren't held back by SBT in future right?