Repository navigation
[MGPG-111] Clean up dependency declarations #254
Description
Elliotte Rusty Harold opened MGPG-111 and commented
[WARNING] Used undeclared dependencies found:
[WARNING] org.apache.maven:maven-artifact:jar:3.9.6:provided
[WARNING] org.apache.maven:maven-settings:jar:3.9.6:provided
[WARNING] com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile
[WARNING] org.apache.maven.resolver:maven-resolver-impl:jar:1.9.18:provided
[WARNING] Unused declared dependencies found:
[WARNING] com.kohlschutter.junixsocket:junixsocket-core:pom:2.9.0:compile
[WARNING] org.codehaus.plexus:plexus-cipher:jar:2.0:compile
Remote Links:
Activity
jira-importer commentedon Mar 8, 2024
Tamas Cservenak commented
Please, do not blindly follow these (broken anyway) reports.
Explanations:
The only "real" issues (2 out of 6, not bad)
jira-importer commentedon Mar 8, 2024
Elliotte Rusty Harold commented
I don't. These reports also help figure out where maven-dependency-analyzer has issues that need to be fixed. The "dependency grouping" pattern is interesting. I haven't encountered that before. I'll have to look into it. Do note that junix-socket common is reported as used but undeclared, so perhaps it does need to be declared.
plexus-sec-dispatcher and plexus-cipher I'm not sure about. It sounds like there might be a better way to handle this.
If maven-resolver-impl is used in test, then perhaps the scope is wrong or perhaps this is a bug in maven-dependency-analyzer. I know it's had problems with test dependencies before.
jira-importer commentedon Mar 8, 2024
Tamas Cservenak commented
Re junixsocket, in fact BOTH are used (but one goes undetected, as is native):
https://repo.maven.apache.org/maven2/com/kohlschutter/junixsocket/junixsocket-core/2.9.0/junixsocket-core-2.9.0.pom
This is how POM looks and even description tells "this is the one you want to add as dependency".
About "dependency grouping": https://blog.sonatype.com/2009/10/maven-tips-and-tricks-grouping-dependencies/
Note: this technique predates BOMs, but is IMHO maybe better than BOMs as they do work in "maven way", unlike BOMs. See MNG-8009, MNG-7906, MNG-5971 and many others.
jira-importer commentedon Mar 9, 2024
Elliotte Rusty Harold commented
so com.kohlschutter.junixsocket:junixsocket-common:jar:2.9.0:compile is used but not declared. Definitely something to fix. In fact, it sems klikely 3 if not 4 of Used undeclared dependencies detected should be fixed.
plexus-cipher needs further investigation.
junixsocket-core might need some thought as to how the dependency analyzer can recognize this.
jira-importer commentedon Mar 9, 2024
Elliotte Rusty Harold commented
Interesting blog article. After reading it, I'm not surprised that maven-dependency-analyzer doesn't pick up "dependency grouping". It's essentially a hack that uses undeclared transitive dependencies instead of declared direct dependencies,. I suppose you might make a case for that, but it's the opposite of what maven-dependency-plugin: analyze is trying to check. My personal opinion is that developers should bite the bullet and declare all their direct dependencies and only direct dependencies. Use a BOM to set versions of related projects, but not to add dependencies to the tree.
Anything else runs counter to the design of Maven and the Maven repository system, and will cause more problems than it solves.The design of the Maven repo system is far from perfect, but it's what we've got, and we can't hack changes into it. Anything better would require a complete rethink of everything beyond jar files and classpaths. It's the classic antipattern of someone wishing the system were other than it is, and trying to pound the round peg into a square hole by using a bigger hammer. Other examples of this antipattern include "functional" programming in Java, various schemes to avoid declaring and handling checked exceptions, and any number of faster XML parsers that achieve speed by changing or subsetting the XML spec.
jira-importer commentedon Mar 9, 2024
Tamas Cservenak commented
Aye, modern tools like takari-lifecycle would even forbid using it. In fact, it enforces that whatever you touch (at source level) be declared as direct dependency. See here http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
jira-importer commentedon Mar 15, 2024
Tamas Cservenak commented
This is the best I can (and feel right):
As explained: junixsocket tells you to use the POM dependency (that brings in one java and one native dependency). Analyze sense java one as "undeclared but used" (is used), and completely misses the native one, while tells that directly added POM is unused.
Also commented that plexus-sec-dispatcher and plexus-cipher simply "must go both" (together).
jira-importer commentedon Mar 15, 2024
Tamas Cservenak commented
3.2.1 is due for urgent bugfix (breaks GnuPG in CI-like env), so we can continue this on other issue if needed.