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