bootRepackage should use a classifier instead of an extension

[toolforger]

Currently, bootRepackage renames the original jar to xxx.jar.original.
It would be better to follow Maven's convention to use a classifier for this, i.e. to rename the file to xxx-original.jar so that it follows Maven's classifier format.

(This came up while I was writing up #1113.)

[snicoll]

Is it strictly a naming issue or do you intend to say that the original jar should be deployed alongside the modified one with such classifier? Thanks.

[toolforger]

Just naming.

I'm not aware that bootRepackage does any deployment. This is about making the work of deployment plugins easier, by following standard naming conventions for them.
Also, this implies that the original jar should not be renamed, since "no classifier" is usually considered to mean "the library jar, suitable for inclusion as a build dependency in another project". Executables should probably have another classifier, though I'm not aware of any convention for a classifier; I picked .boot in #1113 as an example, but there are other reasonable choices.

[snicoll]

We could reconsider changing the name of the "original" jar file but I disagree that the executable should have a classifier. Two reasons for that:

1. It is the main artifact when you decide to include the boot plugin in your lifecycle.
2. The story is java -jar target/foo.jar. It will break and will be less nicer if we start adding a classifier in there. I wouldn't do that.

So, foo-1.0.0-SNAPSHOT-original.jar would be better than foo-1.0.0-SNAPSHOT.original.jar. I still don't see anything obvious that would work in a smoother way if we do this (which deployment plugin exactly?).

Thanks!

[bep]

There are many start-up scripts out there on the form java -jar target/*.jar that will break if more than one.

[snicoll]

Yep, @philwebb any comment?

[philwebb]

Not having a .jar extension was intentional and I'm not keen to change it for no good reason. I'm not sure I'm actually seeing an issue here, I believe that you could still attach the artifact using build-helper or ant-run.

I think I'll close this one for now unless someone has a "I want to do X" type problem with the current design.

[toolforger]

Well, "I want to do X", for X in:
1️⃣ "I want to see #1113 resolved, other than as wontfix"
2️⃣ "I want to see Gradle not unnecessarily rebuilding the jar".

#1113 will retrigger this issue with reason 1️⃣ if #1113 decides to keep the separate bootRepackage task: You can't rename ${archivesBaseName}.jar to ${archivesBaseName}.jar.original without breaking Gradle's up-to-date logic for the jar task.

2️⃣ remains relevant until #1113 is fixed.

Until then, for the benefit those being sent here by Google in search of a workaround for 2️⃣, here's mine (freshly tested):

def renameFile(oldName, newName) {
    new File(oldName).renameTo(new File(newName))
}

bootRepackage.doLast {
    // Work around https://github.com/spring-projects/spring-boot/issues/1113
    renameFile("${libsDir}/${archivesBaseName}.jar", "${libsDir}/${archivesBaseName}-boot.jar");
    renameFile("${libsDir}/${archivesBaseName}.jar.original", "${libsDir}/${archivesBaseName}.jar");
}

[philwebb]

I actually thought that this issue was talking about the Maven plugin, not the Gradle plugin so apologies for talking at cross purposes. Lets see what we can do for #1113 before re-opening this one.

[toolforger]

Confirming that #1113 essentially fixes this.
Seems that my attempt at a separation of concerns turned out to just obscure the overall picture instead of achieving anything productive. Ah well, sorry for the confusion.