Support WARs.

[coollog]

Thumbs up if you would like Jib to be able to containerize applications normally packaged as WARs.

[bennettdong]

Is there a timeline for this?

[coollog]

@Xiangfeid We are actively working on this issue and welcome input for solutions from anyone in the community. We expect a solution to be provided by the 0.10.0 version milestone.

@chanseokoh will be able to guide the conversation and design

[YJFinBJ]

I have issue in "comand and tomcat war support #646"

[chanseokoh]

For documentation after some preliminary research:

pom.xml of an example Maven WAR project:

  <packaging>war</packaging>
  <version>0.1.0-SNAPSHOT</version>

  <groupId>com.example</groupId>
  <artifactId>war-example</artifactId>

1. $ mvn package

2. $ cat > target/Dockerfile <<EOF
   FROM gcr.io/distroless/java/jetty:debug
   
   # By convention, the exploded WAR directory is <artifact-id>-<version>.
   COPY war-example-0.1.0-SNAPSHOT /jetty/webapps/ROOT
   
   ENTRYPOINT ["java","-jar","/jetty/start.jar"]
   CMD []
   EOF
   

3. $ docker build -t my-app-on-jetty target/
4. $ docker run -p 8080:8080 -t my-app-on-jetty

The app will be available at localhost:8080. I expect the Tomcat base image would not be too different from this flow.

There are other images like the official Jetty Docker image and the Google-maintained Jetty runtime image, but I think we'll stick to the distroless Jetty. I hope it enabled all the typical web app support like JSP and JSTL.

[briandealwis]

So we could put WEB-INF/classes in one layer, WEB-INF/lib in a second layer, and everything else in a third layer. Does that make sense?

Updated: oh we should do the same -SNAPSHOT separation too.

[coollog]

Yep! Should be fairly simple to write an adapter for this war format once #516 is merged.

[tofflos]

What if you have a thin WAR and need a complete application server? Currently I do this to get a complete MicroProfile stack:

FROM payara/micro
ARG WAR

COPY $WAR $DEPLOY_DIR

[loosebazooka]

@tofflos, are you wondering about provided deps? We do not include provided deps so if MicroProfile is providing them for you that's fine.

In the case of the app server, you would still pull payara/micro. The one issue is determining $DEPLOY_DIR, we will have a provision for custom application locations, our default case will probably support distroless/jetty though.

[joelhandwell]

gretty is one of widespread gradle plugins for war app development and jib integration would be great.

[CyrilleH]

Hello,

I added some code to support "exploded" WAR projects with the gradle plugin (in my forked repository).

Here you will find an example of use.

Maybe it may help...

[coollog]

@CyrilleH Thanks for sharing this!

[chanseokoh]

Task tracking:

• propagate WorkingDir (issue: Propagate container configuration from base image? #595 (comment) / PR Propagate WorkingDir in container configuration #902)
• propagate ExposedPorts (issue: Propagate container configuration from base image? #595 (comment))
• propagate Cmd and Entrypoint (issue: Propagate container configuration from base image? #595 (comment), Add Support for use CMD to start container #924 / PR Inherit ENTRYPOINT and CMD from base image for WAR projects #1071)
• add ZipUtil for unzipping WAR (PR: Add unzip util method #906, Eliminate Zip-Slip vulnerability #908)
• support for exploded WAR layer configuration and distroless Jetty default entry (PR Preparation for Gradle WAR support #917)
• refactor JavaLayerConfiguration to allow configuring files in a flexible way (issue Change JavaLayerConfiguration.set___Files to use the new API to add source files #1007 / PR Reorganize JavaLayerConfigurations API about getting extraction path for Docker context generation #1010 / PR New JavaLayerConfiguration API for more flexibility #1049 )
• container.appRoot for configuring the application root (issue Add "container.appRoot" config parameter #964 / PR Add container.appRoot config parameter #984)
• fine-grained multiple layers instead of a single exploded WAR layer (PR Proposal War support with Gradle #923)
• Gradle WAR support (PR Proposal War support with Gradle #923)
  • Follow-ups: PR Minor cleanups after merging WAR Gradle support contribution #1072, Issue Gradle WAR build may fail due to non-existing "WEB-INF/lib" in exploded WAR directory #1074, PR Check if WEB-INF, WEB-INF/lib, and WEB-INF/classes exist #1077
• Maven WAR support (PR Maven War support #1068)
  • Explode the final WAR instead of working on the exploded WAR directory (Issue Explode WAR instead of working on exploded WAR directory for Maven #1091)
• infer suitable appRoot for base popular images (Jetty / Tomcat / ? ...)
• update docs (including container.appRoot) (PR Update README for 0.10.0 #1147)
• add a WAR example (PR #??? as a working sample / PR Update README for 0.10.0 #1147 as a doc)
• add integration tests (PR Set up integration test for Gradle WAR image building #1094 Add WAR integration test using Tomcat #1097 Add Jetty/Tomcat WAR integration tests for Maven #1100 Add WAR integration tests for exportDockerContext #1106)

Refactoring and cleanups:

• Be consistent with evaluating Maven and Gradle parameter values #1090: setting the default base image and the app root
• Reuse code for JavaLayerConfigurations for WAR project between Maven and Gradle #1089: code reuse for WAR layer configuration between Maven and Gradle
• Consider removing ProjectProperties.isWarProject() #1088: cleanup

[coollog]

Hi everyone, version 0.10.0 has been released with support for WARs!

[mvysny]

Hi @coollog thank you very much! Is this feature documented please, or is there an example project for this?
EDIT: pardon me, it's at https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#war-projects