Make messages.js files available as assets by implementing an asset generator

[francisdb]

Would it not be better to have this plugin as an asset generator?

It is currently needing a play application instance to retrieve the messages, but maybe I could get rid of this dependency by re-implementing the messages file parsing process. I will think of this for a 2.0 version ^^

[julienrf]

Once the 1.6.0 will be ready I will be happy to merge a pull request implementing this. I’m not sure I’ll have time to implement it by myself.

[francisdb]

ok, might give a shot at it once 1.6.0 is out

[johdah]

Is there any documentation on how to implement an asset generator?

[francisdb]

you could check these projects https://github.com/patiencelabs/play-stylus https://github.com/jlitola/play-sass

[francisdb]

@johdah let me know if you have a go at it...

[johdah]

Yes

[johdah]

I chose to write a Python script to do the conversion instead and let Intellij trigger it when I changed the language files.

[francisdb]

Had a go at implementing this, quick and dirty

issues:

• no filtering yet
• dirty hack to access package private play messages reader
• large copy paste from play AssetsCompiler because needs some tweaks
• no namespace configuration yet
• todo: start by reading play config "application.langs" and build files for all those languages + fall back to default lang if no specific messages file found
• the play app is not available, can currently only read messages files in conf, might be better to build the play classpath and searching it like on runtime (would this be possible?)
• ugly println's for debug

https://github.com/francisdb/play-jsmessages/commit/baf27d89a28e78d2dc0ee2389bfeb6fb85e9db94

how to use: Publish locally in sbt

publishLocal

Add the settings to your play project

.settings(jsmessages.plugin.JsMessagesPlugin.jsmessagesSettings:_*)

Add the plugin to plugins.sbt

addSbtPlugin("org.julienrf" % "jsmessages-plugin" % "1.6.0-SNAPSHOT")

messages.xxx.js files should end up in the javascripts in the resources_managed folder

What do you think? Something to build upon? Worth the hassle?

[julienrf]

messages.xxx.js files should end up in the javascripts in the resources_managed folder

I think it would be better if messages could still be shared between server-side and client-side. Is it possible to keep the conf/messages.xxxx location?

Otherwise, does the new way to handle assets in Play 2.3 change something? Maybe we should make an sbt-web plugin?

[francisdb]

I suppose you misunderstood me? I'm just saying where the .js versions are generated. Not that you have to move the messages.xxx files. No idea bout 2.3, big changes?

[julienrf]

I'm just saying where the .js versions are generated. Not that you have to move the messages.xxx files.

Ok, great!

No idea bout 2.3, big changes?

It seems.

[francisdb]

The hard part is to reproduce the play messages classpath loading without a running play application. Everything else is quite trivial. Related to 2.3, I see no change in trunk, last commit to the asset compiler was 7 months ago.

[francisdb]

Hmm, looks indeed linke we should switch to an actual sbt plugin http://www.playframework.com/documentation/2.3.x/Migration23

The above example shows SbtWeb being added to the root project of a build. In the case of SbtWeb there are other plugins that become enabled if it is e.g. if you also had added the sbt-less-plugin via addSbtPlugin then it will become enabled just because SbtWeb has been enabled. SbtWeb is thus a “root” plugin for that category of plugins.

[johannesschobel]

sorry to pick this old issue up.. what is the status of this?

[julienrf]

It has not been implemented. You can give it a try, if you want :)

[johannesschobel]

haha, i am not a scala developer (yet) but i will add it to my todo-list.. maybe some time later :D thanks for the fast response! all the best and happy new year