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.
Comment From: dratler
Hi @philwebb I have created a PR for this issue
Comment From: 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.
Comment From: 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
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: zarembo
well, it is not great, but this is how it works. 😞 I will keep the branch and maybe it will change in future.