Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump jakarta.xml.bind-api from 3.0.0 to 3.0.1 #271

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Apr 28, 2021

Bumps jakarta.xml.bind-api from 3.0.0 to 3.0.1.

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

Bumps jakarta.xml.bind-api from 3.0.0 to 3.0.1.

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added the dependencies Pull requests that update a dependency file label Apr 28, 2021
@sonarcloud
Copy link

sonarcloud bot commented Apr 28, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@slawekjaranowski slawekjaranowski merged commit 477e7bb into master May 1, 2021
@slawekjaranowski slawekjaranowski deleted the dependabot/maven/jakarta.xml.bind-jakarta.xml.bind-api-3.0.1 branch May 1, 2021 10:44
pzygielo pushed a commit to pzygielo/pgpverify-maven-plugin that referenced this pull request May 31, 2024
…ersion ordering (s4u#271)

Our two collector implementations produce slightly different dirty trees when in transitive dependencies ranges are in use. The new BF produces (w/ and w/o skipper) produces this dirty tree:
```
menforcer426:aid:ext:1 compile
+- menforcer426:bid:ext:1 compile
|  +- menforcer426:cid:ext:3 compile
|  +- menforcer426:cid:ext:2 compile
|  \- menforcer426:cid:ext:1 compile
+- menforcer426:cid:ext:3 compile
+- menforcer426:cid:ext:2 compile
\- menforcer426:cid:ext:1 compile
```
The "old" DF produces this one:
```
menforcer426:aid:ext:1 compile
+- menforcer426:bid:ext:1 compile
|  +- menforcer426:cid:ext:1 compile
|  +- menforcer426:cid:ext:2 compile
|  \- menforcer426:cid:ext:3 compile
+- menforcer426:cid:ext:1 compile
+- menforcer426:cid:ext:2 compile
\- menforcer426:cid:ext:3 compile
```

Spot the difference: the two dirty trees are "semantically" (or content-wise?) equal/same, except for the artifact ordering, where there was a version range (collector in this case discovers available versions that "fits" range and created nodes for them, one for each version that lies within version constraint). DF collector relies and provides "metadata based" ordering (as metadata contained the versions), while BF explicitly sorts them in descending order (for internal optimization purposes). Point is, both dirty trees are ok.

But, Conflict resolver in verbose mode for two inputs above produces different outputs. For DF with "divergence found",  while for BF "no divergence found" (correctly).

Overall changes in this PR:
* most are test and test related resources
* cosmetic changes like javadoc typos, adding override etc
* added reusable `DependencyGraphDumper`
* key changes are in `ConflictResolver` covered by `ConflictResolverTest` UT changes
* overall fix is to make `ConflictResolver` insensitive to input dirty tree version ordering, make sure output is same for "semantically" (or content-wise?) same inputs.

How tested this:
* built/installed this PR
* built maven-3.9.x with this resolver
* ran maven IT suite -- OK
* ran apache/maven-enforcer#259 w/ built maven (so fixed resolver is used). This PR contains only one reproducer IT that fails with any released Maven version -- OK w/ maven built as above.

Just realized how enforcer ITs are good source of inspiration for resolver use cases, so many if not all of new tests are actually inspired by enforcer ITs.

---

https://issues.apache.org/jira/browse/MRESOLVER-345
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Development

Successfully merging this pull request may close these issues.

1 participant