This message was deleted.

In the compile classpath you probably have the compiled classes directory directly instead of the jar as it is unnecessary for compilation to build the jar first. But yes, this very much reads like a code smell what you do there. Why do you try to get that version there?

The version used of this library is recorded so we know exactly what is used in the production build - which ends up using a fat jar. We want to know the actual version in case a transient dependency bumps it. The compiled classes directory would be included indirectly by the

includeBuild

logic, but it knows what dependency is being substituted and with what version. Since the

runtimeClasspath

gets the info, I expected

compileClasspath

would still work.

Where do you want to know it? At runtime / from the built production archive?

Whatever version that got bundled into the fat jar, we want to know that from the built production archive. We add this info to the fat jar manifest.

"my-library" sounds for me like it is a library by your own. When I want to get the version of an artifact at runtime, I usually generate that info into some file in the actual artifact in the build of that artifact. Usually in some properties file and with that a class that reads that file and can provide the version information conveniently even at runtime. Maybe that would also be an option for you?

You are describing something similar to the manifest field we are adding to the fat jar. These lines of Gradle script are the "generating that info into some file" part 😄 . The jar manifest is where version information goes when the jars are separate, this is just incorporating that information into the fat jar for this particular dependency that is important for our troubleshooting.

I do, but for that very same reason (people following that imho horrible practice to build bad-practice fat jars where also the manifest information is lost) I tend to not generate it into the manifest, but into some resource file in the jar where it will be preserved even with a fat jar. And the generation I talk about is done in the build of "my-library", not within the consumer, depending on jars being available, names being as expected, and using questionable Gradle logic like using

copyRecursive

for that and resolving configurations at configuration time which brings a lot of other problems too eventually. 🙂

I don't disagree, I don't really like fa jars myself, but that was decided long before my involvement. Let's assume the fat jar is happening and I'm not going to win the battle to get rid of it. This could be written to an external dependency manifest file of some sort as far as that goes, but stuffing everything in the fat jar does make things a bit easier for some of the people involved as it remains a single unit that can't easily be separated from the metadata. As for the questionable Gradle logic - is there a better way to do it? Assuming I still want to get the version of a dependency somehow and it has to also work when I choose to use

includeBuild

because I am working on that library and the code that uses it.

As I said, my recommendation would be to generate that information within the build of "my-library" and write it to some file that does not get lost during fat-jarring. Then you don't need the Gradle-logic in the downstream build as the information is preserved during repacking.

This needs to work for libraries that we don't build as well.

Whether there is a better / cleaner version of what you posted originally I'm not sure, as I never tried to do such logic. But if you really need to keep that, maybe going on the runtime classpath is the ad-hoc solution.