0
votes

We are in the process of upgrading an application of ours from Play 2.3(.10) to Play 2.4(.6). In development environment, assets are found and deployed as expected. In deployment, however, they are not. We're using sbt-native-packager 1.1.1 and activator clean stage in the building step. The generated files work but the assets are not copied into a /public directory in any of the generated JARs. Instead, I find them in some directories named

META-INF/resources/webjars/<project>/
  <branch>-<commit>-<builddate>/javascripts/jquery-2.1.1.min.js

in the generated <projectname>-assets.jar file. With Play 2.3, this JAR contains the file from above as

public/javascripts/jquery-2.1.1.min.js

as expected.

The result is that the assets are not found and Error 404 is delivered. The route is the usual

GET  /assets/*file  controllers.Assets.at(path="/public", file)

In the templates, the asset is referenced as

<script type="text/javascript" src="@routes.Assets.at("javascripts/jquery-2.1.1.min.js")"></script>

which leads - as expected - to

<script type="text/javascript" src="/assets/javascripts/jquery-2.1.1.min.js"></script>

in the generated HTML delivered to the browser. From what I see, everything is exactly as described in the documentation. In development environment, everything works. But after the deployment the pieces are not coming together...

What is going on here? Why do I get something with "webjars" in the path when we're not using webjars at all? Why are the assets not in "public"? How can I get this working? Is there some plugin or sbt setting in the way?

UPDATE 2016-06-02

In the meantime we found out that the assets are actually generated correctly in the first place:

[info] Packaging /home/xy/workspace/<project>/target/<project>-<version>.jar ...
[debug] Input file mappings:
[debug]         public/javascripts/ckeditor/plugins/a11yhelp/dialogs/lang/fr-ca.js
[debug]           /home/xy/workspace/<project>/public/javascripts/ckeditor/plugins/a11yhelp/dialogs/lang/fr-ca.js

Later in the stage process, however, the same file is generated again - and now with the wrong file locations:

[info] Packaging /home/xy/workspace/<project>/target/<project>-<version>.jar ...
[debug] Input file mappings:
[debug]         META-INF/resources/webjars/<project>/<version>/javascripts/ckeditor/plugins/a11yhelp/dialogs/lang/fr-ca.js
[debug]           /home/xy/workspace/<project>/public/javascripts/ckeditor/plugins/a11yhelp/dialogs/lang/fr-ca.js

I have already tested to manually modify the JAR file after sbt's build finishes: If I move that META-INF/resources/webjars/<project>/<version> directory to a simple public/ and repackage the JAR (outside sbt), everything works perfectly well. So, I have my "plan B" ready but I would really like to understand, (a) why sbt is operating wrongly here and (b) how to make it operate correctly...

1

1 Answers

1
votes

Ok, we finally got it. Deeply buried in our ever growing build.sbt there was this nice snippet:

// Name of the produced artifact
artifactName := { (sv: ScalaVersion, module: ModuleID, artifact: Artifact) =>
  artifact.name + "-" + module.revision + "." + artifact.extension
}

It came from one of the very, very first stages of our transition to sbt as build tool back in 2013. It might even be that it was from the official Play or sbt tutorial back then (Play 2.1, sbt 0.12...). It survived until today. And it caused the <project>-<version>-assets.jar containing the assets below public/ to be falsely named <project>-<version>.jar. Lateron the real <project>-<version>.jar with the assets below META-INF overwrote the asset-containing JAR file. And that's how things went wrong.

The fix was to disable - or better: remove - that artifactName definition from build.sbt. Now, everything is fine and we finally can continue with the migration to Play 2.4.