sbt-pack icon indicating copy to clipboard operation
sbt-pack copied to clipboard

ResourceNotFoundException when using custom Mustache templates in Linux

Open thomasschoeftner opened this issue 11 years ago • 6 comments

It seems that sbt-pack (or the contained Scalate invocation) cannot find custom script template (Mustache) file Linux. The URI works on windows, but I get a ResourceNotFoundException when running in Linux. Other Linux tools can successfully resolve the URI, though. - It seems structurally correct.

Acc. to the stack trace Scalate's doesn't find the resource. Maybe it has something to do with the way that Scalate is invoked?

Stack trace:

org.fusesource.scalate.util.ResourceNotFoundException: Could not load resource: [file://../../abc.mustache]
    at org.fusesource.scalate.util.ResourceLoader$class.createNotFoundException(ResourceLoader.scala:58)
    at org.fusesource.scalate.util.FileResourceLoader.createNotFoundException(ResourceLoader.scala:61)
    at org.fusesource.scalate.util.ResourceLoader$class.resourceOrFail(ResourceLoader.scala:55)
    at org.fusesource.scalate.util.FileResourceLoader.resourceOrFail(ResourceLoader.scala:61)
    at org.fusesource.scalate.util.UriResource.delegate(Resource.scala:91)
    at org.fusesource.scalate.util.DelegateResource.text(Resource.scala:216)
    at org.fusesource.scalate.mustache.MustacheCodeGenerator.generate(MustacheCodeGenerator.scala:126)
    at org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:750)
    at org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:699)
    at org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:419)
    at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:413)
    at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:471)
    at org.fusesource.scalate.TemplateEngine.layout(TemplateEngine.scala:573)
    at xerial.sbt.Pack$$anonfun$packSettings$20$$anonfun$apply$31.apply(Pack.scala:225)
    at xerial.sbt.Pack$$anonfun$packSettings$20$$anonfun$apply$31.apply(Pack.scala:208)
    at scala.collection.TraversableLike$WithFilter$$anonfun$foreach$1.apply(TraversableLike.scala:772)
    at scala.collection.immutable.Map$Map1.foreach(Map.scala:109)
    at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:771)
    at xerial.sbt.Pack$$anonfun$packSettings$20.apply(Pack.scala:208)
    at xerial.sbt.Pack$$anonfun$packSettings$20.apply(Pack.scala:99)
    at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
    at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:42)
    at sbt.std.Transform$$anon$4.work(System.scala:64)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
    at sbt.Execute.work(Execute.scala:244)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
    at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:160)
    at sbt.CompletionService$$anon$2.call(CompletionService.scala:30)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:679)

thomasschoeftner avatar Apr 03 '14 13:04 thomasschoeftner

Edit: I have tried with pack 0.4.3 and 0.5.2-SNAPSHOT. - The same error occurred with both version.

The stack trace actually originates from a custom built version where I've tried this: https://groups.google.com/forum/#!topic/scalate/q6HC-9n1WW0 ... it didn't help!

thomasschoeftner avatar Apr 03 '14 13:04 thomasschoeftner

This part simply invoking Scalate. https://github.com/xerial/sbt-pack/blob/develop/src/main/scala/xerial/sbt/Pack.scala#L223

And Scalate engine is created in a normal way: https://github.com/xerial/sbt-pack/blob/develop/src/main/scala/xerial/sbt/Pack.scala#L223

I guess it's a classloder issue if the resource can be found in a classpath.

xerial avatar Apr 04 '14 05:04 xerial

Nope, it's not a classloader issue. It seems that scalate has problems resolving mustache files which are outside the folder where sbt or the application is executed.

Example: My project is in repo/sources/project/. The mustache files, however, are outside in repo/templates/xy.mustache Specifying a relative path (in the sbt-pack settings) to the mustache files outside the sbt project always leads to that problem.

I looked at the scalate code and it essentially loads any URL... It's definitely a problem with Scalate...

thomasschoeftner avatar Apr 04 '14 09:04 thomasschoeftner

using a canonical file to load the Template - rather than loading the template by URI - seems to work... I'll test it out and send a pull request if it works

thomasschoeftner avatar Apr 04 '14 10:04 thomasschoeftner

Thanks. So copying the script resource to some tempolary file, then let Scalate load it. 2014/04/04 19:51 "thomasschoeftner" [email protected]:

using a canonical file to load the Template - rather than loading the template by URI - seems to work... I'll test it out and send a pull request if it works

— Reply to this email directly or view it on GitHubhttps://github.com/xerial/sbt-pack/issues/34#issuecomment-39552856 .

xerial avatar Apr 04 '14 11:04 xerial

Pull request created - it contains a fix. The templates are specified via paths (not URLs) relative to the root project... Let me know what you think...

thomasschoeftner avatar Apr 04 '14 11:04 thomasschoeftner