| Hello Mark. I understand your points. However, I think that if there are some clients using dependencies induced transitively from Jenkins, they should declare those dependencies directly in their poms: it is a good practice to explicitly specify the dependencies that projects are using directly (see https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html). Anyways, this is not a severe problem for clients since it can be fixed easily just adding the dependency, and it is very important for Jenkins to keep its dependency tree as simple as possible and stay out of dependency bloat. Dependencies become unused due to the natural evolution of software projects, if we decide to never remove them, then the project will continuously adding dependencies due to the concerns of breaking some clients' code. Why should Jenkins maintain the unused dependency commons-codec in module cli? To me, there is no reason to serve functionalities out of the Jenkins' API. On the other hand, the same version of dependency jdom is added and excluded in the pom of the core module**, which is completely redundant (even more if we consider that this dependence is not even used). Perhaps such dependency changes should be considered for the next release. |
