Add option for spring-boot-maven-plugin:repackage goal to always generate filenames using group and artifact name

[u3r]

When packaging two dependencies with same artifact name + version (but different groupID) the spring-boot-maven-plugin:repackage goal already adds the groupID to the packaged filename (see ArtifactsLibraries.java:doWithLibraries()

For better traceability within the produced fat-jar I'd like to have an option in the repackage configuration to force the inclusion of full GAV for all artifacts. Otherwise (badly named) artifacts with common names like core common are not immediately obvious.

[dratler]

Hi @philwebb I have created a PR for this issue

[wilkinsona]

Maven's war plugin provides an outputFileNameMapping for this purpose, the usage of which is described here. It seems like a good source of inspiration and I think it makes sense to align with something that Maven users may already be familiar with.

If we make this possible with Maven, we should also consider what, if anything, we want to do for Gradle. It's already possible with Gradle without any changes to Boot with some configuration like this:

tasks.named('bootJar') {
    rootSpec.rename { fileInJar ->
        def artifact = project.configurations.runtimeClasspath.resolvedConfiguration.resolvedArtifacts.find { it.file.name == fileInJar }
        return artifact ? "${artifact.moduleVersion.id.group}-${fileInJar}" : fileInJar
    }
}

It assumes that everything in BOOT-INF/lib will have come from the runtimeClasspath. This assumption will hold true in most cases. It's not as declarative as something like Maven's outputFileNameMapping but it is far more flexible. Internally we have LayerResolver which provides some more sophisticated mapping of a file that's being copied into a jar to its dependency coordinates. We could, perhaps, build something like outputFileNameMapping on top of this if we wanted a simpler, more declarative configuration model that would look something like this:

tasks.named('bootJar') {
     outputFileNameMapping = "${groupId}-${artifactId}-${version}.${ext}"
}

Given the above, I don't think this issue is ideal for contribution. We need to make some design decisions before it can progress.

[zarembo]

@wilkinsona I created a fork and implemented the mapping as you described in your comment from 14 Feb. 2022
It is currently only implemented in 2.7, but it is not a problem to add the feature to newer releases.
Would this be an option to be merged?
My branch is: 2.7.x-filemapping

[wilkinsona]

@zarembo Thanks for taking a look but, as I said above when describing the status of this issue, "we need to make some design decisions before it can progress". We haven't done that design work and, unfortunately, until we have, it won't be possible to review any possible contributions. One thing I can say is that any change in this area will only be added to a new 3.x minor release at the earliest.

[zarembo]

I fully understand your answer. A feature should never be a fast shot. But may I ask if a design discussion might be something in near future? The last activity is almost an year old.

[wilkinsona]

I think that's unlikely I'm afraid. This issue isn't particularly high priority as very few people appear to be affected by it and we have plenty of other higher priority things on our plate at the moment.

[zarembo]

well, it is not great, but this is how it works. 😞
I will keep the branch and maybe it will change in future.