With a few exceptions, the Maven repackaging leaves META-INF
at the root of the jar. With Gradle, everything gets moved beneath BOOT-INF/classes
.
Comment From: nrheckman
I discovered the difference when attempting to build container images for use with Dataflow. The labels it uses to fill in the configuration weren't present when built via gradle but are when built via maven.
Some steps to reproduce the issue:
The expected behavior when using Maven can be seen via the following steps:
curl -G https://start.spring.io/starter.tgz -d dependencies=webflux -d type=maven-project -d baseDir=demo-maven | tar -xzvf -
cd demo-maven
mkdir src/main/resources/META-INF
echo "configuration-properties.names=server.port" > src/main/resources/META-INF/dataflow-configuration-metadata.properties
./mvnw spring-boot:build-image
docker inspect demo:0.0.1-SNAPSHOT |grep "org.springframework.boot.spring-configuration-metadata.json"
While the following shows the resources in the wrong location, thus not getting recognized for label generation:
curl -G https://start.spring.io/starter.tgz -d dependencies=webflux -d type=gradle-project -d baseDir=demo-gradle | tar -xzvf -
cd demo-gradle
mkdir src/main/resources/META-INF
echo "configuration-properties.names=server.port" > src/main/resources/META-INF/dataflow-configuration-metadata.properties
./gradlew bootBuildImage
docker inspect demo:0.0.1-SNAPSHOT |grep "org.springframework.boot.spring-configuration-metadata.json"
Comment From: wilkinsona
Thanks, @nrheckman.
The problem can also be reproduced using ./mvnw package
and ./gradlew bootJar
and then examining the contents of the resultant jars.