Incorrect link order when resolving nearest dependencies.
Adam Ciaccio
As advertised, Maven will pull in all the 'nearest' dependencies of a given project however the link order is not always correct. For example if project A-1.0 specifies B-1.1 and C-1.0 as dependencies IN THAT ORDER (i.e. in A's pom.xml) the build fails to link because C-1.0 depends on B for symbols that are optimized out of the build. The resulting link line looks like the following:
-lB1.1 -lC1.0
The correct link line should be the following:
-lC1.0 -lB1.1
If however I list A's dependencies with C-1.0 first (i.e. C-1.0 B-1.1) then the build succeeds because B-1.1 will be placed in the link line AFTER C-1.0 and therefore satisfies all symbols needed by both A and C. Inspection of the maven NAR code shows that NAR pulls the 'reduced graph' of dependencies required for the build. That is, when NAR makes a call to DependencyGraphBuilder.buildDependencyGraph (...), the resulting graph does not include C-1.0's dependency on B-1.0 so the NAR plug-in will not have sufficient information on how much further down in the link order B-1.1 must be placed.
One implementation to solve this problem would be to pull both the dependency graph and the dependency tree (DependencyTreeBuilder.buildDependencyTree(...)) in AbstractDependencyMojo's methods for parsing the dependencies and constructing the dependency string. The NAR plug-in could use the set of dependencies from the reduced graph as the source of truth for which library versions to use and could then parse the 'full dependency tree' to identify how far down the link line to place those libraries in the methods of AbstractDependencyMojo.
Curtis Rueden
--
You received this message because you are subscribed to the Google Groups "NAR Maven plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-nar+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.