loader tools: fix NONE layout (no launcher class, no libraries)

[patrikbeno]

Existing NONE Spring Boot layout is an extension of JAR layout and as such it includes all the dependencies in lib/ folder. This is wrong. NONE layout should be empty. Nothing. Void.

For context, see https://github.com/patrikbeno/spring-boot/wiki/Requirements

[philwebb]

I believe this is intentional. @dsyer added it so he can probably say for sure. Without adding dependencies to /lib wouldn't none just be the same as setting bootRepackage.enabled = false?

[patrikbeno]

The idea is that repackager may do other things than messing up with archive layout. In may populate manifest with custom SpringBoot metadata, for example. So you may not want to disable it completely.

My understanding was that NONE layout is used in unit testing and has no real world application.

Anyway, let's wait for what @dsyer has to say.

[dsyer]

I think I just added it because the plugin might do other things than layout a jar.

[philwebb]

@panchenko I don't think we should change the current implementation for NONE. This PR along with #2620 feels like a general way to add new layouts might be useful.

[patrikbeno]

@philwebb, while I agree with the way you're heading, let me put it this way:

Do you think current implementation of the NONE layout is reasonable?
Or, are you concerned about introducing breaking changes?

Anyway 1st, even if we don't change NONE layout, at the very least it should be renamed because it is confusing.

Anyway 2nd, if NONE should be unaffected, we need some NULL, VOID, NOOP, NADA layout that will not change layout at all, and just lets SpringBoot plugin do whatever other tasks it does or will do.

Anyway 3rd, maybe we should drop fixed enum-based layouts completely, and instead reference layout by class name. With this approach, one could implement his own crazy layout from scratch, add new implementation as build-time dependency, and off you go, you have pluggable layouts.

With respect to backwards compatibility, we may introduce mapping of the legacy enum layout names to actual class names currently being used. Hence, we can introduce fundamental architecture change regarding pluggable layouts, while providing full backward compatibility.

[patrikbeno]

I suggest we close this and go with #2629

However, I still think NONE is a bad name for a pretty useless layout. Initial motivation as described by @dsyer is perfectly OK but NONE should not inherit from JAR. Just saying.