Pull Maven artifacts - invalid version

dean-houston

Hi @michal-roszak_0767 , @steviecoaster ,

Maven versioning is a total mess. v*** is indeed an invalid version, per the which means that (among other things) it must be lexicographically sorted for determining latest version.

It looks like they knew that enough to use a string... but not enough to use a valid version number. Oh well. /rant

If you go to Manage Feed Settings, you can enable invalid versions in the feed. The message should make this more clear, so I will clarify that via PG-2977 in the next maintenance release.

-- Dean

steviecoaster

Well, it makes my eyes bleed

michal.roszak_0767

@dean-houston,
@steviecoaster

"If you go to Manage Feed Settings, you can enable invalid versions in the feed."
As you know, this setting doesn't work.
Either in GUI or command line uploads.

https://forums.inedo.com/topic/5387/proget-versioning-restrictions/5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.911 s
[INFO] Finished at: 2025-05-08T16:35:55+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project CARE: Could not resolve dependencies for project eu.example:CARE:jar:0.5.1-SNAPSHOT
[ERROR] dependency: io.github.java-diff-utils:java-diff-utils:jar:4.16-SNAPSHOT (compile)
[ERROR]  Could not find artifact io.github.java-diff-utils:java-diff-utils:jar:4.16-SNAPSHOT

Cheers,
Michal

dean-houston

Hi @michal-roszak_0767 ,

That error is unrelated to invalid versions being allowed/disallowed in ProGet. Maven is just saying that it can't find a snapshot (i.e. prerelease) version of a dependency.

'io.github.java-diff-utils:java-diff-utils' is a public library, published to Maven Central:
https://repo1.maven.org/maven2/io/github/java-diff-utils/java-diff-utils/

Snapshot versions are not published to Maven Central. I don't know where it's published.

In any case you should not be using snapshots of public libraries unless you have a very specific need to; they're only intended for development of related public libraries and are in a special repository. Check w/ the devs behind that build with their intents... it might be a mistake?

-- Dean

michal.roszak_0767

@dean-houston

I think you right.
It might be a mistake.

And my bad that I didn't checked by myself, but it's a lot of going on here.
We just implement ProGet software in our company (payment in progress).

Thanks,
Michal

michal.roszak_0767

@dean-houston

One more thing I've noticed.

I can download artifact manually:

wget https://proget.server/maven2/maven-maven-org/com/google/javascript/closure-compiler/v20250407/closure-compiler-v20250407.jar
--2025-05-09 10:10:50--  https://proget.server/maven2/maven-maven-org/com/google/javascript/closure-compiler/v20250407/closure-compiler-v20250407.jar
Resolving proget.server... *******
Connecting to proget.server|******|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://proget.server/maven2/maven-maven-org/com/google/javascript/closure-compiler/v20250407/closure-compiler-v20250407.jar/ [following]
--2025-05-09 10:10:51--  https://proget.server/maven2/maven-maven-org/com/google/javascript/closure-compiler/v20250407/closure-compiler-v20250407.jar/
Reusing existing connection to proget.server:443.
HTTP request sent, awaiting response... 200 OK
Length: 1727 (1,7K)
Saving to: ‘closure-compiler-v20250407.jar’

closure-compiler-v20250407.jar                      100%[=================================================================================================================>]   1,69K  --.-KB/s    in 0s

2025-05-09 10:10:51 (969 MB/s) - ‘closure-compiler-v20250407.jar’ saved [1727/1727]

But I still can't see this file in Web UI.
No cache.

Why?

Michal

michal.roszak_0767

@dean-houston,

Where can I find file "maven-metadata.xml" in ProGet file structure?

Michal

dean-houston

Hi @michal-roszak_0767,

After looking into this further, I'm afraid we simply can't support this artifact/package at this time. I don't really see a good path for supporting this without adding significant complexity and risk of breaking proper artifacts / versions.

The problem is that this version breaks the basic rules that Maven repositories need to follow:

Artifact Names / Groups cannot start with a digit
Versions must start with a digit

These rules resolve the ambiguity of determining what /com/google/javascript/closure-compiler/v20250407 means. For example, is it:

Files for version v20250407 of com.google.javascript.closure-compiler artifact?
All versions of the com.google.javascript.closure-compiler.v20250407 artifact?

I'm not even sure how this was uploaded to Maven central. I have no idea why the developers ignored the warnings that Maven spat out for legal version numbers. This has been a specification for like 20 years. Heck, here's a discussion from like 2008 on how the "must start with a digit" rules needed clarification: https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning

If you encounter other artifacts like this, maybe we can consider some kind of very limited exception, but until we figure something else out this artifact version is simply not supported in ProGet.

I can't imagine there are many other artifacts like this, but let us know if there are.

-- Dean

dean-houston

@michal-roszak_0767 ProGet is not a file server. Metadata files like maven-metadata.xml are generated upon demand, based on artifacts stored in the feed

michal.roszak_0767

Hi @dean-houston,

Thank you for you patience :)
Two more questions:

it is possible to use wildcards searching artifacts. Can I search only in name (without description)?
how to change License Assignment for an artifact?

Regards,
Michal

dean-houston

Hi @michal-roszak_0767 ,

ProGet does not support wildcards searching for artifacts.

Licenses are declared in the manifest (i.e. .pom file):
https://maven.apache.org/pom.html#Licenses

You cannot really override this. If an artifact does not have a license, you will be given a chance to pick a license for it. If you ever need to change that, you'd have to go to the SCA > Licenses > License Types, and remove the package-specific assignment from there.

-- Dean

michal.roszak_0767

@dean-houston

Strange...
If I type "jaudio*" in search prompt I'll get:

What is this if not wildcard search?

Michal

michal.roszak_0767

OK... I see. Asterisk is ignored.
Sad...

michal.roszak_0767

@dean-houston said in Pull Maven artifacts - invalid version:

Hi @michal-roszak_0767,

After looking into this further, I'm afraid we simply can't support this artifact/package at this time. I don't really see a good path for supporting this without adding significant complexity and risk of breaking proper artifacts / versions.

The problem is that this version breaks the basic rules that Maven repositories need to follow:

Artifact Names / Groups cannot start with a digit

Versions must start with a digit

These rules resolve the ambiguity of determining what /com/google/javascript/closure-compiler/v20250407 means. For example, is it:

Files for version v20250407 of com.google.javascript.closure-compiler artifact?

All versions of the com.google.javascript.closure-compiler.v20250407 artifact?

I'm not even sure how this was uploaded to Maven central. I have no idea why the developers ignored the warnings that Maven spat out for legal version numbers. This has been a specification for like 20 years. Heck, here's a discussion from like 2008 on how the "must start with a digit" rules needed clarification: https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning

If you encounter other artifacts like this, maybe we can consider some kind of very limited exception, but until we figure something else out this artifact version is simply not supported in ProGet.

I can't imagine there are many other artifacts like this, but let us know if there are.

-- Dean

Next victim:
https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/

Michal

dean-houston

@michal-roszak_0767 said in Pull Maven artifacts - invalid version:

Next victim:
https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/

jeeze, what a mess!

Well, there goes any hope of using v[0-9]+ -- they just straight up use random strings as version numbers.

Open to ideas, but based on the URLs alone... I don't see a good way to identify one of these as an artifact and the other as a version of an artifact.