Support for Grails 4

Environment:

• Jib version: 2.4.0
• Build tool: Gradle 5.1.1
• OS: Windows 10

Description of the issue: Unable to use jib with Grails 4. When attempting to do so, it appears that Grails Views are not assembled into the Docker image, leading to HTTP 500 errors when viewing pages.

Grails has a guide for integrating with Docker using gradle-docker-plugin or manually available here: https://guides.grails.org/grails-as-docker-container/guide/index.html. At that location, you can download a zip file that has an initial Grails project and a Grails project that integrates with gradle-docker-plugin. There is currently not documentation on integrating Grails with jib.

Expected behavior: Commands “gradle jib”, “gradle jibDockerBuild”, and “gradle jibBuildTar” assemble Grails Views into the Docker image.

Steps to reproduce:

1. Download the zip file here: https://guides.grails.org/grails-as-docker-container/guide/index.html#howto and unzip to use the “initial” project.
2. Apply jib plugin to build.gradle.
3. Use any of the above three commands such as “gradle jibBuildTar” to build the Docker image. Then load the image and run it in Docker.

Jib config I’ve removed the from and to images, but the configuration looks like this:

jib {
  from {
    image = '...'
  }
  to {
    image = '...'
  }
}

[chanseokoh]

Thank you very much for the sample app and the detailed information. This will immensely help the Jib community. To emphasize that we recommend disabling the war plugin, I have updated your earlier and last comments. I have confirmed that the image built by Jib works (after I installed the missing Gradle wrapper binary and ran the compileGsonViews task). We will look into the sample to see if there’s an alternative for Grails+Jib. Thanks for sharing your insights!

[sosguthorpe]

I understand that Jib doesn’t use the bootJar task, the config was to make Grails behave in a consistent way. Disabling the war task would mean a none-executable jar by default. Enabling the bootJar task causes the Grails gradle plugin to change how it’s configured. It was totally grails specific.

I created a Hello World App for you to look at. While I did that I noticed 2 things.

1. When the default tomcat-based spring boot starter is used then the war based image creation fails to start. Tomcat specific logging implementation fails inside the Jetty based container. My project I use Jib with uses the undertow-based starter and that seemed to work OK. I recommend, and we always personally do here, using the jar task based output with Grails and commenting out the war plugin.

   // Commenting out the war plugin is recommended when using with Jib. The default tomcat
   // spring boot starter used by Grails doesn't play nicely with the default jetty image used by jib.
   // Commenting out the war plugin will cause jib to use the outputs of the jar gradle task, which seems to work
   // well.
   // apply plugin:"war"
   

2. One of the grails plugins’ (cache), dependents (gpars) adds a second conflicting version of groovy all to the classpath, which when expanded by jib causes an exception. I added the exclude to the build.gradle file, I personally don’t use that plugin and commenting it out will also make the collision go away.

       // Cache plugin depends on GPars, which causes a conflicting version of groovy all on the classpath when used with JIB
       compile ("org.grails.plugins:cache") {
         exclude group: 'org.codehaus.groovy', module: 'groovy-all'
       }
   

The hello world app was created by executing:

$ grails create-app org.world.grails-jib-hello --profile=rest-api

and the only modifications beyond that are the ones documented here to the build gradle file.