layout/asset issues with distTar/distZip

[zyro23]

currently, app assets are put into myapp-0.1.jar/assets/....
that works when used with java -jar myapp-0.1.jar.
however, distTar and distZip are building distributions with a structure of myappdir/libs/myapp-0.1.jar where the app jar resides next to the other dependency jars (no fat jar).
that again means myapp-0.1.jar is searched for assets like a lib jar/binary plugin (META-INF/assets) and so, the assets are not found.

steps to reproduce:

grails create-app myapp
cd myapp
gradlew build
cd build/distributions
tar xf myapp-0.1.tar
./myapp-0.1/bin/myapp

then http://localhost:8080 will show the default index.gsp without properly loaded assets.

i opened this one here in grails-core because it does somehow span grails-core/grails-gradle-plugin, asset-pipeline and asset-pipeline-core.

related question: why are assets not just always put into META-INF/assets when a jar is built (no matter if app/lib/plugin)? does the differentiation of putting the app assets into .jar/assets allow asset-pipeline to distingiush between app assets and lib/plugin assets (overridability)? if so, has that been tested with a multi-module project where the modules are "libs" in the end?

thanks, zyro

[graemerocher]

Good questions, maybe @davydotcom can chip in with an answer

[davydotcom]

This is a good question. It has to do with what is considered "processed" assets and "unprocessed" assets. In a jar/lib/plugin these assets are not processed. They are not minified, nor digested, nor transpired. They are "raw" in this sense in META-INF/assets.

This may be making you ask why they need to be and why we cant preprocess/minify them. The answer is minification only works when you bundle everything together due to the globbing of variable names. Once more it is possible to override things in your application that are not in your lib like say for Bootstrap you might override variables.less. Therefore you would need to process the assets.

So your final jar or dist package puts all processed assets in the classpath:/assets area. Along with a manifest.properties which has the alias names for the digest.

[zyro23]

ok. raw vs. processed assets understood so far.
given this example: grails create-app assettest, cd assettest, grails package
two things remain unclear (for me, at least):

1. jar

build/libs/assettest-0.1.jar:/assets/ contains multiple variants of the same asset. default mobile.css (which has no require directives) results in the jar file as:

mobile-97bf65813ed089c730d3c570d6973f4d.css
mobile-97bf65813ed089c730d3c570d6973f4d.css.gz
mobile.css
mobile.css.gz

with the .css files being minified (one-liners) - is that the expected behavior?

2. distTar / distZip

build/distributions/assettest-0.1.zip:/lib/assettest-0.1.jar has the assets packaged in jar:/assets/ as well but this app jar is treated as a lib jar (because it is no fat jar). i guess for this case, the jar should contain the raw assets in jar:/META-INF/assets/ (as u explained), right?

update: or maybe not. thinking about this, the processed assets have to reside somewhere. i just do not know why they are not found in jar:/assets/.

my current ugly workaround is to duplicate the assets by (re-)adding this to build.gradle:

jar {
    from("${buildDir}/assetCompile") {
        into "META-INF"
    }
}

but this does only work because of 1. and its no solution at all because it bloats the artefact by duplicating assets...

thanks again for your feedback! zyro

[zyro23]

the "workaround" does not work reliably and i am at the point that im not sure anymore this has to do wih asset-pipeline. when running the distTar app and index.gsp is shown with broken styling, looking at the html shows that layouts/main.gsp is not applied anymore at all. does not happen all the time.
it points in the direction of a classpath resource loading issue.
closing this and i will reopen a new issue once im more certain what the problem really is.

[davydotcom]

I'm seeing the same with the layout

Sent from my iPhone

On Jul 14, 2015, at 7:42 AM, zyro notifications@github.com wrote:

the "workaround" does not work reliably and i am at the point that im not sure anymore this has to do wih asset-pipeline. when running the distTar app and index.gsp is shown with broken styling, looking at the html shows that layouts/main.gsp is not applied anymore at all. does not happen all the time.
it points in the direction of a classpath resource loading issue.
closing this and i will reopen a new issue once im more certain what the problem really is.

—
Reply to this email directly or view it on GitHub.

[zyro23]

@davydotcom thx for confirming the behavior! does it work for you, too, if u run the dist runscript/bat from within the app dir?

[davydotcom]

No i get a missing layout issue. It has nothing to do with asset-pipeline that I can tell

[zyro23]

@davydotcom sry to bother u again but trying to find the root cause i commented out the <asset:xyz> tags from layouts/main.gsp and the layout is applied again o.O
however, asset tags put directly into ìndex.gsp are resolved correctly...

can u confirm that? and maybe you, or @graemerocher any idea what might be going on here?

thanks, zyro

[graemerocher]

@zyro23 Maybe if an example could be uploaded with steps to reproduce?

[zyro23]

@graemerocher that would be no problem but it would be a blank grails app. steps from initial description still lead to the incompletely rendered view.

grails create-app myapp
cd myapp
gradlew build
cd build/distributions
tar xf myapp-0.1.tar
./myapp-0.1/bin/myapp

[graemerocher]

Ok I see, will investigate..

[davydotcom]

gradle install-dist

Go to build/install/bin and run it you'll see it

Sent from my iPhone

On Jul 15, 2015, at 5:07 AM, graemerocher notifications@github.com wrote:

Ok I see, will investigate..

—
Reply to this email directly or view it on GitHub.

[zyro23]

an additional observation:

• if i just run the dist, the layout is not rendered at all.
• if i edit the runscript, moving $APP_HOME/lib/myapp-0.1.jar from the beginning of the CLASSPATH= line to its end (: separator), the layout is rendered but the <asset:xyz> tags inside the layout are not

[zyro23]

reopened with edited title

[zyro23]

fwiw, looking at #9100, #9115, #9117 i tried to down-/upgrade asset-pipeline to 3.0.1/3.0.4 but behavior remained unchanged.

[jasonschwab]

In a Grails 3.0.3 project, adding runtime "org.grails.plugins:asset-pipeline:3.0.1" to the build.gradle file seemed to resolve the issue for me when building a war file via gradle clean war -Dgrails.env=production and deploying into Tomcat 8.

[ww2]

I also experienced the missing-asset problem (the grails logo wasn't displayed, stylesheets weren't applied) when deploying a grails-3.0.4 application via a war file under Tomcat 8, and can confirm that changing the line in build.gradle's dependencies section from

runtime "org.grails.plugins:asset-pipeline"

to

runtime "org.grails.plugins:asset-pipeline:3.0.1"

(and rebuilding, and redeploying) appears to have resolved those issues.

[zyro23]

this one is not about war deployments on a tomcat but "standalone" distZip or distTar distributions. those do still not work for me. i tried up to asset-pipeline-3.0.6.

[zyro23]

just checked and issue still present with grails-3.0.5/asset-pipeline-3.0.8

[graemerocher]

Just a note on this, in Grails 3.1 M1 (and Spring Boot 1.3) the TAR / ZIP distributions are no longer built, since we no longer rely on the Gradle application plugin (only a JAR or WAR is produced). Given this, I'm tempted to mark this as "Won't Fix" as the application plugin will not be supported in the next version of Grails and this feature was only present due to the a side effect of it being there.

[zyro23]

so it is fair to say fat-jar and war are the recommended/supported ways of building/deploying application artefacts? if so, please go ahead closing this one. if really required, a shell script and/or win bat file launching the fat-jar are quickly written, too. thx! zyro

[graemerocher]

Yes it is the recommended way