Javadocs not always working for -SNAPSHOT versions

[mfnalex]

What happened?

Hi, when I mvn deploy one of my things as a -SNAPSHOT version, the javadocs link in the browser is sometimes not working. I don't really know when or why this happens, but it only seems to happen for multi-module maven artifacts that use -SNAPSHOT in the version.

Example: https://repo.jeff-media.com/#/public/com/jeff-media/jefflib/jefflib-core/13.0.0-SNAPSHOT

If you go there, you'll notice there's a javadoc .jar called jefflib-core-13.0.0-20230817.140707-1-javadoc.jar. When I click on the "book" button to open the javadoc browser though, it tries to open jefflib-core-13.0.0-20230817.140707-2-javadoc.jar instead, which in turns correctly tells me that this doesn't exist:

{"status":404,"message":"Cannot find 'com/jeff-media/jefflib/jefflib-core/13.0.0-SNAPSHOT/jefflib-core-13.0.0-20230817.140707-2-javadoc.jar' in local and remote repositories"}

Reposilite version

3.x

Relevant log output

No response

[joshuasing]

Hi, I have reproduced this bug with the steps you provided.

Currently, Reposilite uses the following code to determine the latest snapshot version:

reposilite/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocContainerService.kt

Lines 66 to 73 in dc03731

	if (version.contains("-SNAPSHOT")) {
	val metadataResult = mavenFacade.findMetadata(repository, rootGav)
	val snapshot = if (metadataResult.isOk) metadataResult.get().versioning?.snapshot else null
	if (snapshot?.timestamp != null && snapshot.buildNumber != null) {
	version = "${version.replace("-SNAPSHOT", "")}-${snapshot.timestamp}-${snapshot.buildNumber}"
	}
	}

I had a look at the maven-metadata.xml file for the artifact that was used in your example (https://repo.jeff-media.com/public/com/jeff-media/jefflib/jefflib-core/13.0.0-SNAPSHOT/maven-metadata.xml) and noticed:

    <snapshot>
      <timestamp>20230817.140707</timestamp>
      <buildNumber>2</buildNumber>
    </snapshot>

This issue seems to be caused by the build number here being 2, whereas the artifacts have the build number 1.
This causes Reposilite to look for a javadoc .jar file with the build number 2, which does not exist.

I am currently unsure of what is causing the build numbers to differ, and as soon as I have some more spare time, I will investigate further.

[mfnalex]

Hi, thanks for the quick reply. I am unsure why maven produces this "2" buildNumber - maybe it helps if I link the repo for that artifact? (You probably won't be able to build it as it relies on many minecraft libraries that are not available in any public repository - there's a "run-buildtools.sh" file included that install all required dependencies, but I doubt you wanna run that haha): https://github.com/JEFF-Media-GbR/JeffLib However the pom doesn't do any funny things. Hmmm...

[joshuasing]

I was finally able to reproduce this issue in Maven yesterday.
I ran into a configuration issue (that I am still yet to resolve) that caused the Maven deploy plugin to run twice.

When this happens, it appears that each run bumps the buildNumber in the metadata - however only the first one increments the build number in the artifact names, thus causing this problem.

Could you check whether this occurs when you publish your artifacts?

[dzikoysk]

It sounds quite strange, I wonder if it's intended behavior of Maven deploy plugin 🤔