These are chat archives for fiji/fiji

Mar 2018
Jean-Yves Tinevez
Mar 26 2018 07:00
@ctrueden fixed, thanks!
Curtis Rueden
Mar 26 2018 12:18
Philipp Hanslovsky
Mar 26 2018 13:25
For people who prefer command line, you can also run:
mvn dependency:tree
Curtis Rueden
Mar 26 2018 15:20
@hanslovsky Beware: mvn dependency:tree does pruning, unlike the Eclipse UI.
Philipp Hanslovsky
Mar 26 2018 15:28
@ctrueden I am not 100% sure what that means but definitely good to know (and somewhat unexpected).
Curtis Rueden
Mar 26 2018 16:23

@hanslovsky It means the dependency tree listed by dependency:tree can be incomplete compared to the one given by Eclipse. For example, the dependency:tree for net.imagej:imagej says:

[INFO] +- net.imagej:imagej-legacy:jar:0.29.0:runtime (optional)
[INFO] |  +- net.imagej:ij1-patcher:jar:0.12.8:runtime (optional)
[INFO] |  +- net.imagej:ij:jar:1.51s:runtime (optional)
[INFO] |  +- net.imglib2:imglib2-ij:jar:2.0.0-beta-39:runtime (optional)
[INFO] |  +- org.scijava:scijava-search:jar:0.4.0:runtime (optional)
[INFO] |  +- org.scijava:scijava-ui-awt:jar:0.1.6:runtime
[INFO] |  +- org.scijava:scijava-ui-swing:jar:0.9.5:runtime
[INFO] |  |  +- org.scijava:swing-checkbox-tree:jar:1.0.2:runtime
[INFO] |  |  \- net.sourceforge.jdatepicker:jdatepicker:jar:1.3.2:runtime
[INFO] |  \- org.javassist:javassist:jar:3.22.0-GA:runtime (optional)

But imagej-legacy has additional dependencies such as imagej-common. The imagej-common dependency is not shown because it is already a direct dependency of imagej. So even though it is also inherited transitively, this fact is not visible from the output. So if your goal is to add exclusions to stop all leakage of a particular dependency, this tool is only sufficient if you check the tree iteratively.

Philipp Hanslovsky
Mar 26 2018 17:41
Ugh, that's frustrating. Thanks for the clarification @ctrueden
Jan Eglinger
Mar 26 2018 17:43
Would using mvn dependency:tree -Dverbose make any difference?
Curtis Rueden
Mar 26 2018 17:56
@imagejan "Verbose not supported since maven-dependency-plugin 3.0"
My understanding, from my time reading the Maven mailing list, is that the dependency resolution mechanism was changed rather deeply between Maven 2 and Maven 3, and in particular the maven-dependency-plugin works quite differently between v2 and v3. I guess v2 was hackier but better in some ways, whereas v3 is more well architected but ends up being less flexible/powerful? That might be a misrepresentation/oversimplification, though.