[MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver

[andrzejj0]

See summary; also: dependency:tree is no longer necessary to check parent information of dependencies which triggered validation failures -- path information is included.

@slawekjaranowski please review

[andrzejj0]

I see. I was under the impression that the API for custom rule creators was the enforcer-api module. That was at least what I used when I created the custom enforcer rule in versions-maven-plugin. Didn't know AbstractBanDependencies was intended to be used as API for external rules. Perhaps it should be stated more clearly that it's also part of the API for custom rules.

[andrzejj0]

Closed by mistake... 👀

[andrzejj0]

@olamy could you have a look as well? Thanks!

[andrzejj0]

Also resolves [MENFORCER-434]

[andrzejj0]

I'd also gladly use a DependencySelector to exclude artifacts already at the dependency node retrieval level, but if you say everything is public API, I'm not sure whether I am allowed to modify any class. @slawekjaranowski could you please help out?

[andrzejj0]

Looks like javadoc linter was upset with BannedDependenciesBase (which I'd rather not have and use the old AbstractBannedDependencies instead). Corrected.

[slawekjaranowski]

Please squash to final commit and rebase with current master

[andrzejj0]

Rebased and squashed.

[andrzejj0]

@slawekjaranowski your newest it failed. Checking.

[andrzejj0]

It's been so long that I had forgotten the reasons why I did things like I did -- e.g. use bespoke dependency selectors instead of the regular ones (the reason for that being that the out of the box selectors only work on transitive dependencies).

So I commented that piece.

[andrzejj0]

I mean, it would be nice if there were also selectors working on direct dependencies, but that would require changes (PR) to Resolver 🤡

[pzygielo]

Seems it might have caused MENFORCER-466, as 919fe02 is reported as first bad commit.