https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Don't choose a generic name like 
core
? That's alway totally unhelpful when you try to identify a jar and can lead to such clashes.
e
well to be honest, i can turn the question arround
why ever consider using only the artifact id as the filename when it is known that is is not the FQDN and not unique therefore
i mean when i publish this to the nexus, i do not publish it into a flat folder but as 'com.project.topic.core' and 'com.project.othertopic.core'
v
That's a convention Maven introduced and how Maven repositories work
e
you mean tha is how the JVM runtmeClass path is search / expanded as? i mean, would it hard renaming the files in BOOT-INF/libs/ to be the FQDN instead?
i assume that is not allowed since it cannot be resolved during runtime, right
v
No, that's not at least related to what I said or meant. I meant exactly what I said.
How you name the files on the classpath is absolutely irrelevant
You can name them 1.jar, 2.jar, and so on, doesn't matter.
But if you have a library in a Maven repository like on Nexus, then the Maven repository format dictates that the name is the artifact name plus version.
e
i see so this actually is an issue of the bootJar task, which packages the spring boot jar with it's dependencies and uses the artifact-id as the filename
v
Well, Gradle could maybe rename those files after download, but that was just not be done
i see so this actually is an issue of the bootJar task, which packages the spring boot jar with it's dependencies and uses the artifact-id as the filename
No, you are just ignoring what I say it seems
e
When the written is not understood, it does not mean that it has not been read/ignored.
v
Well, then you read it and draw conclusions, that have absolutely nothing to do with the written, I'm sorry, but then I cannot help 😞
Usually artifact names should be pretty unambiguous as noone usually uses generic names like "core". And if you make them fully-qualified, you usually only make them longer, which can then lead to problems with length restrictions, even on Windows.
You can of course add logic to rename the jar files and have them named different than practically everyone else. But that's just not the Gradle default. The Gradle default follows what is done since practically forever and also was formalized by the Maven repository format.
e
you mean tha everyone is adding it's project name to the artifact so it stays unique makes it any shorter 🙂
Copy code
org.springframework.boot:spring-boot-starter-amqp
v
Exactly
e
could have just been org.springframework.boot:ampq and ending up to be org.springframework.boot.ampq.jar
v
Could also be ending up to be 
1.jar
, but ... it isn't :-)
e
which is nearly the same lenght. To me, this is obvious just a bad design, it has been introduced and it is just kept. when you have a FQDN and you flatten the entities when you store them, you just cannot use 'the non fqdn' and expect this to be the happy path and then argue this is 'a good choice' But no need to argue, neither you nor me made that decision, i just might now ack on your opinion here. still thank you, you helped me
v
I did not offer any opinion, nor did I argue whether it is a good choice or not. I just told you how the situation is. The choice also was not made by Gradle, it just adapted it to fit into the existing ecosystem. And yes, in that specific case, the length is not much different, but there are quite some other cases where it is much shorter. Not that the length is the main argument. 😄
e
got it, thank you
2 Views
Open in Slack
PreviousNext
Powered by