fix(maven): Reject releases only for Maven Central repository

[zharinov]

Changes

Context

• Closes: extractVersion with postProcessRelease (maven) causes rejected release #32266

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

I'm it sure this is what we want. It's private registries which have the release problems

[zharinov]

Another suggestion is to exclude jetbrains repo, as it doesn't seem to follow the structure we expect anyways (e.g. at the earlier stage we fail to fetch metadata xml for the latest release).

[rarkins]

Does that mean that that repo didn't used to work at all when we used to eagerly check releases?

[zharinov]

Yes, I think it never worked to the full extent, though HTML page is good enough to extract the list of versions (i.e. without metadata)

[rarkins]

Might be better to make this logic configurable?

• never check (no timestamps possible)
• optional (use data if available)
• strict (enforce/filter)

[zharinov]

Isn't it overcomplication, though? Originally we only wanted to skip releases which were found in metadata.xml but don't have corresponding pom file, which breaks maven build. I'm not sure it makes sense outside of Maven Central.

[zharinov]

After all, reject is the strong tool, so we should limit its usage. I actually surprised why I didn't limited it to the Maven Central for the initial implementation.

[rarkins]

I'm pretty sure the problem which Pom checking solves was primarily in in maven central

[rarkins]

Wasn't the bug about extractVersion and not custom registries?

[zharinov]

I think extractVersion isn't relevant

[rarkins]

This is not what we want. This feature was designed for private registries, not maven central