Extract command fails when using jar mode tools from an unpacked jar

[wilkinsona]

If you unpack an uber jar and then run the extract command from jar mode tools, it fails:

$ java -Djarmode=tools org.springframework.boot.loader.launch.JarLauncher extract
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:102)
	at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:64)
	at org.springframework.boot.loader.launch.JarLauncher.main(JarLauncher.java:40)
Caused by: java.lang.IllegalStateException: java.lang.IllegalStateException: Manifest attribute 'Spring-Boot-Classpath-Index' is mandatory
	at org.springframework.boot.jarmode.tools.ToolsJarMode.run(ToolsJarMode.java:56)
	at org.springframework.boot.loader.launch.JarModeRunner.main(JarModeRunner.java:43)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 4 more
Caused by: java.lang.IllegalStateException: Manifest attribute 'Spring-Boot-Classpath-Index' is mandatory
	at org.springframework.util.Assert.state(Assert.java:79)
	at org.springframework.boot.jarmode.tools.IndexedJarStructure.getMandatoryAttribute(IndexedJarStructure.java:137)
	at org.springframework.boot.jarmode.tools.IndexedJarStructure.get(IndexedJarStructure.java:145)
	at org.springframework.boot.jarmode.tools.ExtractCommand.getJarStructure(ExtractCommand.java:214)
	at org.springframework.boot.jarmode.tools.ExtractCommand.run(ExtractCommand.java:113)
	at org.springframework.boot.jarmode.tools.Command.run(Command.java:112)
	at org.springframework.boot.jarmode.tools.Runner.runCommand(Runner.java:68)
	at org.springframework.boot.jarmode.tools.Runner.run(Runner.java:55)
	at org.springframework.boot.jarmode.tools.Runner.run(Runner.java:47)
	at org.springframework.boot.jarmode.tools.ToolsJarMode.run(ToolsJarMode.java:53)
	... 6 more

It would be beneficial for buildpacks if this worked as it would mean that they don't have to zip things back up again.

/cc @anthonydahanne

[wilkinsona]

This is quite a bit more complicated than I'd hoped as it affects how the extract command and its options can be used.

  --destination string           Directory to extract files to. Defaults to a directory named after the uber JAR (without the file extension)

The default no longer works. With an unpacked uber JAR, it's likely that there's already no file extension so you end up with an destination directory that's the same as the input directory which fails as it already exists and isn't empty.

  --application-filename string  Name of the application JAR file. Only applicable when not using --launcher. Defaults to the uber JAR filename

This default also doesn't work. With an unpacked uber JAR, it's likely that there's no file extension so you end up with a jar file that doesn't end with .jar.

Running the extract command against an already unpacked uber jar is something of an edge case – buildpacks may be the only potential users – so I don't think we should expand/change options' descriptions and defaults to describe the situation. Perhaps we could require buildpacks to always specify both --destination and --application-filename instead? I'd like to discuss our options with the team as I'm not sure that the breadth of the changes is worth it and the least bad option may well be to require buildpacks to zip things back up again before running extract.

[philwebb]

Perhaps for --application-filename we could add .jar automatically if the source is a directory. For --destination I think we could fail hard if one isn't specified and the source is a directory.

[philwebb]

I've started looking at this and there are also some issues with our Context object. It's finding the incorrect jar when running exploded.