Pull Maven artifacts - invalid version

[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:

1. Artifact Names / Groups cannot start with a digit
2. 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:

1. Artifact Names / Groups cannot start with a digit
2. 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.

• https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/.
• https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/Neumann-SR9/

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.