I have a Grails application building in an AWS CodePipeline. We recently upgraded from Grails 4 to Grails 5 and now one of the third-party JavaScript packages we use is having a problem because it's being minified somewhere in the build process, but the minification process is not properly renaming a particular variable in all parts of the js file. I'd like to switch the minify option in our build process to whitespace only in order to prevent the js variable names from being renamed/shortened. In my local builds, I use the asset-pipeline plugin in build.gradle to minify the js files and I set the optimization level to whitespace only...which works great...but I'm not sure where/how to do that in the AWS CodePipeline.
In the buildspec.yml file being used in the codepipeline, we are simply installing Grails 5 and then issuing the following command: /root/.sdkman/candidates/grails/current/bin/grails war -Dgrails.env=$GRAILS_ENVIRONMENT
Someone on the team thought the Grails war command might be responsible for the js minification, but I haven't been able to find anything. Hence my question here. Any help would be appreciated.
I figured it out. The minification does occur during the WAR creation. I had to add the following code to the application.groovy file in order to minify whitespace only.
grails.assets.minifyOptions = [
optimizationLevel: 'WHITESPACE_ONLY' //SIMPLE, ADVANCED or WHITESPACE_ONLY
]
I also had to modify the problematic js file by adding a comment to it in order to force that file to be re-compiled.
https://bertramdev.github.io/grails-asset-pipeline/guide/usage.html
Related
If I'm looking at project source code (in Intellij) how can I tell whether the Grails source code I'm looking at is an Application or a Plugin?
I get it that the output of a Grails Application build is a WAR, and a JAR for a Plugin but I can't figure out how to tell the difference by looking at the source code.
Bonus question: If it is a multi-module project, how do I tell which module is the Application and which modules are the Plugins? Or am I missing some important concept here?
Plugins can be run as applications as well and will often have an Application.groovy file. Plugins will have a <pluginname>GrailsPlugin.groovy file which sets up the plugin. In grails 3, this is in /src/main/groovy file structure.
How to disable minifying of .css and .js in my gradle configuration?
OBS: Grails v.2.4.0, Gradle v.1.12 and asset-pipeline v.1.8.7
I have been trying some of the following options:
In Config.groovy
grails.assets.minifyJs = false
grails.assets.minifyCss = false
// as well as some others, but without success
Commenting pipeline-plugin in dependencies.gradle
Commenting assetCompiler.compile() in _AssetCompiler.groovy
What I expect to achieve by doing this is less build time for local deploys and make a new Task for generating a new .war without minifying while still having the old 'war' option for a complete production build.
Run grails clean-all command. It cleared the issue for me after upgrading to asset-pipeline
Ref: Reverse case for these guys: Grails assets not minified
I am using uglify-js-minified-resources plugin to minify the files. But it always minify the files before serving means files minify per request. Is there any setting for it that it minify the files on application startup. Also want to know if closure-compiler is good enought for it.
The YUI War Minify plugin will minify resources at War creation time. This should do what you are looking for.
I've got a Tomcat6 server that runs multiple Instances for two separate grail apps.
When I compile my WAR file for deployment normally
run-app -Dgrails.env=production war test.war
It deploys correctly and everything works as it is suppose too.
The problem is, I don't want the JAR files included in my WAR.
So I use the following command line instead
run-app -Dgrails.env=production war test.war --nojars
Now when my grails app deploys (it doesn't) I get a java.lang.NoSuchMethodError
I have copied the lib folder (from my initial test.war) to the following locations
${catalina.base}/shared/lib
${catalina.home}/shared/lib
${catalina.home}/lib
None of these work.
My catalina.properties all point to the correct locations.
Any ideas?
A few ideas:
BuildConfig.groovy has inherits global, which has the app inherit all of the grails/plugins dependencies. If you change this, it may affect both your build and packaging - plus I have yet to encounter any documentation on what type of other things you can do with the inherits DSL
Grails deployment documentation suggests there is a way to customize which dependencies make it into the war file: http://grails.org/doc/latest/guide/17.%20Deployment.html
Event hooks give you access to provide a closure routine into various stages of the grails lifecycle. Can it strip out framework jars from the final war? Haven't tried that either - only using it to re-write various config files for additional envrionment configuration. However it does look like packaging events are exposed to this API:
http://grails.org/doc/latest/guide/4.%20The%20Command%20Line.html
I started a grails application by grails create-app. For modularity, I feel like it would be better that component be a plugin. Can I convert this application into a grails plugin?
thanks,
Babu.
I never created a plugin based on an application written before but looking at the documentation for grails plugins you can read the following statement:
The structure of a Grails plugin is exactly the same as a regular Grails project's directory structure, except that in the root of the plugin directory you will find a plugin Groovy file called the "plugin descriptor".
So I would suggest to create a new plugin with grails create-plugin *your-plugin-name* and copy all files from your application into the plugin.
In case anyone else is looking, this should be exactly what you need: http://burtbeckwith.com/blog/?p=1973
Excerpt:
So to convert an application to a plugin, the general workflow would
be something like
Create the plugin descriptor, FooGrailsPlugin.groovy. The easiest way to do this is to rungrails create-plugin pluginname and copy the
generated file from there
delete everything from application.properties except the app.grails.version property
if you have jars in the lib directory that are available in a Maven repo, delete them and replace with BuildConfig.groovy dependencies
change any plugin and jar dependencies that are needed for development and testing but not when the plugin is installed to not be
exported, by adding export = false
If you need the _Install.groovy, _Uninstall.groovy, or _Upgrade.groovy scripts (you probably don’t) grab those from the dummy plugin from step 1 (but delete any you don’t need, they’re all
optional)
delete ApplicationResources.groovy if you aren’t using it and don’t depend on resources plugin
move code from BootStrap.groovy init() toFooGrailsPlugin.doWithApplicationContext
and/orFooGrailsPlugin.doWithDynamicMethods and destroy() to
FooGrailsPlugin.onShutdown, and delete BootStrap.groovy
add a dependency for the release plugin in BuildConfig.groovy
delete everything but the log4j configuration from Config.groovy
delete UrlMappings.groovy unless you have exported mappings; only keep the added ones
move bean definitions from resources.groovy to FooGrailsPlugin.doWithSpring and delete resources.groovy
delete grails-app/i18n message bundle files unless you added messages; only keep the added ones
delete everything from grails-app/views that you don’t use (in particular error.gsp,index.gsp, and layouts/main.gsp)
delete everything from web-app that you don’t use (including WEB-INF xml and tld files)
now would be a great time to write those tests you’ve been meaning to get to
create one or more test applications to install the plugin into to ensure that it works as a plugin; consider scripting this
write documentation for how to use the plugin; at a minimum a README file, but Grails gdoc files would be much better (run grails doc
--init to get started)