SpringBoot Repackaging WAR with ZIP artifact duplicates JAR dependencies

With a fresh Spring Boot 3.4.2 Maven WAR project generated from https://start.spring.io/index.html I am observing the following.

If you add a dependency to the pom.xml, say

    <dependency>
      <groupId>org.apache.tika</groupId>
      <artifactId>tika-core</artifactId>
      <version>3.0.0</version>
    </dependency>

and run

mvn clean package spring-boot:repackage

then the generated WAR file under target will contain only

WEB-INF/lib/tika-core-3.0.0.jar

But when the ZIP layout in the spring-boot-maven-plugin is configured, the generated WAR file under target will contain the same exact file twice:

BOOT-INF/classes/WEB-INF/lib/tika-core-3.0.0.jar
BOOT-INF/lib/tika-core-3.0.0.jar

Is this expected? I have been reading https://docs.spring.io/spring-boot/maven-plugin/packaging.html but could not find anything about this specific behavior.

Here is the reproducer:

https://github.com/ilgrosso/springbootwarrepackagezip/tree/master

where

mvn clean package spring-boot:repackage

will repackage with the default layout (which I assume is WAR in this case) and

mvn -PZIP clean package spring-boot:repackage

will repackage with the ZIP layout.

Comment From: wilkinsona

It doesn't really make sense to use the ZIP layout with a war project. As stated in the docs, the ZIP layout is "similar to the JAR layout using PropertiesLauncher". Repackaging a jar (as the ZIP layout does) moves everything in the root of the jar into BOOT-INF/classes and that's what's happening here.

What's your goal here? Why do you want to use PropertiesLauncher with a war file?

Comment From: ilgrosso

The goal is to produce a WAR file to distribute, and allow different users to use that WAR but extend the classpath via different values for LOADER_PATH

Comment From: wilkinsona

As things stand, you'll have to use a custom layout for that. Your layout factory could return a sub-class of org.springframework.boot.loader.tools.Layouts.War that overrides getLauncherClassName() to return org.springframework.boot.loader.launch.PropertiesLauncher.

I suspect that we won't want to add out-of-the-box support for this as wars and the properties launcher are both something of a niche, even more so when used in combination, but let's see what the rest of the team thinks.

Comment From: philwebb

I'd rather not any more complexity in that area, so +1 to using the custom layout.