Expected Behavior
When building an app with boot 2.3.0.M3 the generated JAR has the following entry
> zipinfo build/libs/demo-0.0.1-SNAPSHOT.jar
...
-rw-r--r-- 2.0 unx 2360 bl defN 20-May-14 10:34 BOOT-INF/classpath.idx
Actual Behavior
When building the same app with boot 2.3.0.M4 the generated JAR has the following:
> zipinfo build/libs/demo-0.0.1-SNAPSHOT.jar
...
---------- 2.0 unx 1708 bl defN 80-Jan-31 19:00 BOOT-INF/classpath.idx
Impact
When the JAR is extracted to a unix filesystem classpath.idx
is unreadable. Because of this, 2.3.0.M4
JARs are unusable with the paketo java buildpacks which attempt to create an image layer from the exploded jar.
Comment From: scottfrederick
@ekcasey This issue was fixed in 2.3.0.RC1
Duplicate of #20927
Comment From: wilkinsona
Thanks, Scott. I was just typing that I couldn't reproduce this with 2.3.0 snapshots. FWIW, I get the following with both Maven and Gradle:
-rw-r--r-- 2.0 unx 639 bl defN 20-May-14 16:01 BOOT-INF/classpath.idx