[MSHARED-788] Add functionality to collect raw dependencies in Maven 3+

[jira-importer]

Gabriel Belingueres opened MSHARED-788 and commented

Add funcionality allowing to collect raw project dependencies. Add a layer to hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether.

This could be used to implement dependencyConvergence and requireUpperBoundDeps enforcer rules.

---

Affects: maven-dependency-tree-3.0, maven-dependency-tree-3.0.1

Issue Links:

• MENFORCER-280 Enforcer dependency convergence stumbles on selenium-java
  ("blocks")
• MENFORCER-277 Upgrade maven-dependency-tree to 3.x
  ("is required by")
• MSHARED-801 Add functionality to collect raw dependencies in Maven 3+
  ("supercedes")
• MSHARED-339 DependencyGraphBuilder does not provide verbose tree
  ("supercedes")
• MENFORCER-267 Upgrade to make Maven 3.1+
  ("is depended upon by")

Remote Links:

• GitHub Pull Request #1
  

[jira-importer]

Karl Heinz Marbaise commented

You know of the component maven-artifact-transfer which has already a layer for Sonatype Aether and Maven 3.1+ eclipse aether ?

BTW: Maybe I misunderstand the issue here but a dependencyConvergence rule already exists in Maven Enforcer ? And also requireUpperbounds ?

[jira-importer]

Gabriel Belingueres commented

Hi Karl.

Yes I've been looking at maven-artifact-transfer...seemed to me a library pretty much as dependency-tree 3.x. Asked a question on the mailing list...no answers.

About the Enforcer rules, I did not meant to re implement them again, but to make them work again when upgrading to maven-dependency-tree 3.0.x. As a matter of fact, I used the Enforcer project ITs to test this component.

Anyway, you may want to hold the merge as I discovered that it pass all Enforcer tests with dependencyConvergence and requireUpperBounds, but it doesn't retrieve the right component versions in more elaborated cases...I will be committing over this PR when I could finally solve them.

[jira-importer]

Karl Heinz Marbaise commented

Hi Gabriel Belingueres, an answer on mailing list can take time in particular over holidays...
The maven-artifact-transfer lib is intended for install, deploy and resolve artifacts in Maven 3. which would give you the chance the concentrate only on solving the tree problems in dependency tree without having to bother about Aether etc. and yes currently maven-artifact-transfer is being used already in several plugins which you might think based on the version 0.10.1 ...but this means on the other hand we can change/enhance it to our needs or maybe you have needs to for that lib as well...

Ok Now I understand your intention that you like to make Enforcer with Maven 3+ only working correctly...which would be great...and I appreciate your help here....Just ping me if you need help or support...also don't hesitate to do that on the mailing list....

[jira-importer]

Gabriel Belingueres commented

Hi Karl Heinz Marbaise. I pushed some changes to the PR, in case you have time for review it. I don't know if it's final but I think I made some progress.

[jira-importer]

Gabriel Belingueres commented

Moved code to maven-artifact-transfer. Please see MSHARED-801.

[jira-importer]

Sylwester Lachiewicz commented

maven-artifact-transfer is now deprecated.

[jira-importer]

Robert Scholte commented

Fixed in 7e225abf11faf1a0114d735b9aa2ca9f0669c694
I had a look at the maven-artifact-transfer code, but by now it doesn't fit very well.
As this is THE solution to make MENFORCER-267 possible, I've decided to fix it here, so we can have the first 3.0.0 of that plugin.

[jira-importer]

Robert Scholte commented

So it seems with ConflictResolver.push prevents any cyclic node to be resolved, so these have become impossible to detect. I'll remove them from the expected result.

[jira-importer]

Gabriel Belingueres commented

I think it is for the best. In the verbose IT, in the expected-verbose.txt file, there are 3 cases that IMO are wrong (presenting as a cycle the same artifact as a direct dependency):

1. batik-anim:

+- org.apache.xmlgraphics:batik-anim:jar:1.7:compile
| +- (org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-dom:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-ext:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-parser:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-anim:jar:1.7:compile - omitted for cycle)

2. batik_svg-dom:

+- org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
| +- (org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile - omitted for cycle)

 

3. batik-bridge (appears twice as a direct dependency at the same level):

- org.apache.xmlgraphics:batik-bridge:jar:1.7:compile
+- org.apache.xmlgraphics:batik-anim:jar:1.7:compile
| +- (org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-dom:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-ext:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-parser:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-anim:jar:1.7:compile - omitted for cycle)
| +- (org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-util:jar:1.7:compile - omitted for duplicate)
| +- (xml-apis:xml-apis:jar:1.3.04:compile - omitted for duplicate)
| - (xml-apis:xml-apis-ext:jar:1.3.04:compile - omitted for duplicate)
+- org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
| - (org.apache.xmlgraphics:batik-util:jar:1.7:compile - omitted for duplicate)
+- org.apache.xmlgraphics:batik-css:jar:1.7:compile
| +- (org.apache.xmlgraphics:batik-ext:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-util:jar:1.7:compile - omitted for duplicate)
| +- (xml-apis:xml-apis:jar:1.3.04:compile - omitted for duplicate)
| - (xml-apis:xml-apis-ext:jar:1.3.04:compile - omitted for duplicate)
+- org.apache.xmlgraphics:batik-dom:jar:1.7:compile
| +- (org.apache.xmlgraphics:batik-css:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-ext:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-util:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-xml:jar:1.7:compile - omitted for duplicate)
| +- (xalan:xalan:jar:2.6.0:compile - omitted for duplicate)
| +- (xml-apis:xml-apis:jar:1.3.04:compile - omitted for duplicate)
| - (xml-apis:xml-apis-ext:jar:1.3.04:compile - omitted for duplicate)
+- org.apache.xmlgraphics:batik-ext:jar:1.7:compile
| - (xml-apis:xml-apis:jar:1.3.04:compile - omitted for duplicate)
+- (org.apache.xmlgraphics:batik-bridge:jar:1.7:compile - omitted for cycle)
+- org.apache.xmlgraphics:batik-gvt:jar:1.7:compile
| - (org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile - omitted for duplicate)
+- org.apache.xmlgraphics:batik-parser:jar:1.7:compile
| +- (org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile - omitted for duplicate)
| +- (org.apache.xmlgraphics:batik-util:jar:1.7:compile - omitted for duplicate)
| - (org.apache.xmlgraphics:batik-xml:jar:1.7:compile - omitted for duplicate)
+- (org.apache.xmlgraphics:batik-bridge:jar:1.7:compile - omitted for cycle)

 

[jira-importer]

Robert Scholte commented

I don't think it is possible to build a project with cyclic (reactor) dependencies. This seems to be a mistake in batik-poms. You cannot fix them in your own pom and Aether already ensures it is not loaded twice, so that should be fine.
The output related to premanaged versions and omitted for duplicate/version difference look like fixes in the dependency tree (so these were actually bugs in maven 2).
The additional dependencies for batik-script also looks correct to me.

So I think there is 1 thing that needs to be fixed:
org.apache.maven:maven-profile:jar:2.0.4:test (scope not updated to compile)
This looks like a warning where the scope has been reduced to test, whereas it is likely required at runtime.

[jira-importer]

Gabriel Belingueres commented

In addition, please review this line in the current expected output:

| +- (org.apache.maven:maven-model:jar:2.0.5:test - version managed from 2.0.4; scope managed from compile; omitted for conflict with 2.0.7)

while in the generated output is "version managed from 2.0.6", which I think is correct since the dependency is specified without version in org.apache.maven:maven-project:2.0.6 pom.xml.

| +- (org.apache.maven:maven-model:jar:2.0.5:test - version managed from 2.0.6; scope managed from compile; omitted for conflict with 2.0.7)

[jira-importer]

Gabriel Belingueres commented

Another issue: I can't run ITs using maven 3.1.1 or maven 3.0.5:

mvn -Dinvoker.mavenHome=/path/to/apache-maven-3.1.1 clean verify
it fails since it mixes up the local repos.

[jira-importer]

Robert Scholte commented

Currently things that are filtered out with a DependencySelector cannot be added to the tree, because it simply implements boolean selectDependency( Dependency dependency ) without the option to add information to a verbose tree. Ideally I would be able to see all dependencies as specified in the matching pom and see why things are not part of the tree. For test-scoped dependencies this most likely not an issue, but it would be great if you could see that a dependency was removed by exclusion of an ancestor (and which ancestor).
Same counts for cyclic dependencies, but these are already filtered out by embedded code (that behaves like a DependencySelector), so again no way to add this information to the verbose tree without changes to Maven Artifact Resolver.
With that in mind, we can clean up the expected verbose tree.

[jira-importer]

Robert Scholte commented

Fixed with 1e99b437af4428b72a6d9fc944a59538593cd50e