Support building an image when using war packaging with Gradle #23825
Comments
wilkinsona
added
status: waiting-for-triage
wilkinsona
changed the title
|
Here's the output from Things seem to get a bit confused as the executable jar, Tomcat, and Spring Boot buildpacks all get involved. It's not clear to me from the output which will win and, therefore, how the application will be launched. We can run the image and see what happens. Here's the output from doing so: It's a traditional war deployment with our war file being deployed to Tomcat. If a Spring Boot user is building a war file purely to use JSPs (the only reason to use war packaging), a traditional war deployment may not be what they want. In many cases they'll want their executable war to be launched as an executable jar would have been. Among other things, launching an executable war will ensure that the app's choice of embedded container (it may not be Tomcat) and the configuration of it is honoured. @nebhale What's the current state of the art with Paketo and building an executable war-based image? Is it possible today with some config options, or would some builder changes be required for it to support either executable war or traditional war deployments? |
wilkinsona
added
the
status: waiting-for-feedback
|
@wilkinsona The executable WAR thing is really problematic for us because it’s not immediately obvious what the user was intending. In general we have to do some serious surgery (note the lack of the plugin) on an application to get a coherent sample. That sample is the outcome of many people asking why, when they changed a Boot application to The good news is that we’re in a better situation with CNBs than we were with CF buildpacks, because applications don’t need to have be unambiguously one type or another. They can define the same process types in a last-wins priority, they can define multiple process types allowing the user to decide which command to run, etc. I see a couple of options and welcome your opinion on what you’d like to see:
/cc @ekcasey |
spring-projects-issues
added
status: feedback-provided
|
Thanks, Ben. In an ideal world, I think we'd make two things possible:
Generally speaking, I think these two are compatible with you second option. In fact, from a general CNB perspective, I think they're completely compatible. From a Spring Boot perspective things may be a bit trickier, particularly with Maven where I think you may have to jump through some hoops to build a war file without a |
nebhale
added a commit
to paketo-buildpacks/apache-tomcat
that referenced
this issue
Nov 12, 2020
Previously, whenever a WAR, built by Spring Boot was presented to this buildpack confusing things would happen. The fact that the WAR file had both a WEB-INF/ directory (as all WAR files must) and a Main-Class declaration meant that how the WAR file would be run (via an external or embedded Tomcat) was confusing. This change updates the detection logic so that Tomcat is only contributed if both the file is a WAR file and there is no Main-Class declared. [spring-projects/spring-boot#23825] Signed-off-by: Ben Hale <bhale@vmware.com>
nebhale
added a commit
to paketo-buildpacks/apache-tomcat
that referenced
this issue
Nov 13, 2020
Previously, whenever a WAR, built by Spring Boot was presented to this buildpack confusing things would happen. The fact that the WAR file had both a WEB-INF/ directory (as all WAR files must) and a Main-Class declaration meant that how the WAR file would be run (via an external or embedded Tomcat) was confusing. This change updates the detection logic so that Tomcat is only contributed if both the file is a WAR file and there is no Main-Class declared. [spring-projects/spring-boot#23825] Signed-off-by: Ben Hale <bhale@vmware.com>
|
@wilkinsona this has been released and is propagating out to the various places that buildpacks live. |
scottfrederick
added
type: bug
|
Without the |
|
After further discussion, #24521 has been created to replace the unexpected behavior with an error message for current releases. Proper support for image building with war packaging will be a future enhancement. |
scottfrederick
added
type: enhancement
|
Possibly related to #22195 |
scottfrederick
added a commit
that referenced
this issue
Feb 24, 2021
This commit updates the Gradle image building task to support building images from executable and non-executable war files. Fixes gh-23825
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's possible at the moment using a little bit of manual configuration:
The
jarproperty is unfortunately named in this case.archiveorarchiveFilemay be better as it would cover both jars and wars. We could also react to the war plugin being applied and automatically make the configuration change above.The text was updated successfully, but these errors were encountered: