How to dowload the latest release of a Maven artifact?

Help/Discuss
1

Hi
I am still working on a Gradle build script in Kotlin which is intended to pick a bootable JAR archive (stored in a Maven repository) and to build a Docker image with it. With the help of @Vampire I managed to download my Spring-Boot jar from Nexus to a folder on the filesystem using dependencies {...} block.

Now I am trying to download by default the latest published jar in order not to be forced to provide each time the version number (which is like 0.1.0-03ed0dc). Unfortunately I cannot figure out how to define it in the dependency configuration. Indeed when I try this, coming from Gradle documentation:

dependencies {
   ​myDownloads(
       ​group = "com.x.y",
       ​name = "myApp",
       ​version = "latest.release"
   ​)
}

It doesn’t download myApp-0.1.0-1890144.dirty.jar instead of the expected file myApp-0.1.0-cec50f7.dirty.jar as written in maven-metadata-local.xml:

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>com.x.y</groupId>
  <artifactId>myApp</artifactId>
  <versioning>
    <latest>0.1.0-cec50f7.dirty</latest>
    <release>0.1.0-cec50f7.dirty</release>
    <versions>
      <version>0.1.0-1890144.dirty</version>
      <version>0.1.0-cec50f7.dirty</version>
    </versions>
    <lastUpdated>20211207160944</lastUpdated>
  </versioning>
</metadata>

Using version = "0.1.0+" doesn’t work better.

Could someone tell me what is wrong and help me to acheive what I want?

Thanks in advance
Éric

2

I don’t think the maven metadata file is used for that, especially as it is only the view of one repository and if you for example published your jars to JCenter up to now and to Maven Central from now on, you still want the “latest” logic to work.

Here is the version comparison logic described: Gradle User Manual: Version 7.3.1
So your version are split up in the parts

0 / 1 / 0 / 1890144 / dirty

and

0 / 1 / 0 / cec / 50 / f / 7 / dirty

So first three parts are identical and for the 4th part the numeric is considered higher than the non-numeric, thus the 1890144 version is considered later.

Using Git commit SHAs as part of the actual version is never a good idea and one of the reasons I consider JitPack as broken by design when used as main publishing platform instead of doing proper publishing.

3

Hi

Thanks for this quick and precise answer.
If I understand it well, Gradle is ordering its dependencies using strict semantic versionning and only it, isn’t it? So, if I want to get rid of using -SNAPSHOT qualifier during dev (in order to go to some kind of continuous delivery), I have to build a version number which specifies the order of publication.

Éric

4

No, it is not. E. g. Gradle treats some strings specially like rc, final, …, and also considers more than three certain parts, and also considers what semantic versioning defines as build information and says it must be ignored. Basic semantic versions should get ordered properly by Gradle, but even in the pre release part it could result in different ordering.

For continuous delivery, and using “latest” version (which I personally greatly dislike as it works against reproducible builds), you should have properly ordered version numbers, yes.

For preventing SNAPSHOT versions while working on a project and its consumer, I can highly recommend using composite builds.