-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
Hello, I noticed that the dependency org.jvnet.hudson:jtidy is declared in the module core of Jenkins. However, this direct dependency is not used and, therefore, it can be removed safely from this module. I'm intriguing with the exclusion of jdom from org.jvnet.hudson:jtidy in commit https://github.com/jenkinsci/jenkins/commit/fe8df9651a276720f6d9a93ea4fb7d9e3e5a45dc] , because if we look at the dependency tree, we can notice that jdom is not a dependency of org.jvnet.hudson:jtidy.
On the other hand, the transitive dependencies org.jenkins-ci:constant-pool-scanner and net.i2p.crypto:eddsa are not used in the core module and therefore they can be excluded from dependencies org.jenkins-ci.main:remoting and org.jenkins-ci.main:cli, respectively. This makes the core library slimmer, the dependency tree smaller, and the pom clearer.
In addition, the dependency commons-codec is declared in module cli and it is also unused.
Past experiences removing unused dependencies have consistently shown that some code will have depended on that inclusion and will be broken by it. For example, the git client plugin mistakenly included Java classes for some Apache contrib authentication classes. When they were removed (even classes), some downstream consumers were broken and had to include them directly.
When JGit removed the Repository.getRef() call in JGit 5, callers that referenced it had to be reworked to use the replacement calls (findRef or ...).
Have you searched the publicly available Jenkins repositories for potential consumers of the dependencies that are being proposed for removal?
We're not precluded from removing an unused dependency, but I think that the project values compatibility more than removal of unused dependencies, so we need to be careful that removal of an unused dependency does not cause a more severe problem than it solves.