Maven version parse xml rather than html

[felixbarny]

Consider the second commit optional. I can remove it if you don't like it.

[ghost]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-06-08T10:39:12.691+0000

• Duration: 48 min 8 sec

Test stats 🧪

Test	Results
Failed	0
Passed	2957
Skipped	22
Total	2979

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run benchmark tests : Run the benchmark tests.

• run jdk compatibility tests : Run the JDK Compatibility tests.

• run integration tests : Run the Agent Integration tests.

• run end-to-end tests : Run the APM-ITs.

• run windows tests : Build & tests on windows.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[eyalkoren]

I do like the parsing and testing touches, but I think relying on suffix for ordering is not solid.
While this is obvious:

Version.of(1.2.3-SNAPSHOT).equals(Version.of(1.2.3-RC0)) == false

This is just arbitrary:

Version.of(1.2.3-SNAPSHOT).compareTo(Version.of(1.2.3-RC0)) </> 0

The problem is that making those inconsistent could cause trouble specifically in sorted sets (see the Comparable javadoc).

Note that the parsing logic we have now in Version is not necessarily about identifying version prefixes and suffixes as you think about them, but a way to extract the version part out of a string, for example, such that comes from a jar manifest. The redhat httpclient example is real.

Bottom line, I think it's best to make both equality check and ordering rely only on the version numbers, but still maintain the hasSuffix and use it as you already did.

[felixbarny]

The problem is that making those inconsistent could cause trouble specifically in sorted sets (see the Comparable javadoc).

I don't quite get this part as the sort is consistent with equals. While 1.2.3-SNAPSHOT > 1.2.3-RC0 may be arbitrary, it is consistent.

But yeah, overall it seems it doesn't quite work out due to the .redhat suffix thing.

[eyalkoren]

I don't quite get this part as the sort is consistent with equals. While 1.2.3-SNAPSHOT > 1.2.3-RC0 may be arbitrary, it is consistent.

Sorry for not being clear enough. IMO, the best way to reflect versioning equality/comparison logic is:

Version.of(1.2.3-SNAPSHOT).equals(Version.of(1.2.3-RC0)) == false;
Version.of(1.2.3-SNAPSHOT).compareTo(Version.of(1.2.3-RC0)) == 0;

However, I think we should avoid that due to the inconsistency issue.

[felixbarny]

Gotcha, I created a method that lets you remove suffixes. I think that's the best of both worlds. We can ignore suffixes in the element matcher where we know we have to deal with unorthodox .redhat versions.

[github-actions]

/test

[felixbarny]

/test