• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • cli
    • 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.

          [JENKINS-60326] Remove unused dependencies from Jenkins CLI

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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.

          César Soto Valero added a comment - - edited

          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.

           

          César Soto Valero added a comment - - edited 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.  

          Oleg Nenashev added a comment -

          I moved CLI to JENKINS-60325, because it was de-facto delivered

           

          Oleg Nenashev added a comment - I moved CLI to  JENKINS-60325 , because it was de-facto delivered  

          Oleg Nenashev added a comment -

          Ugh, this ticket is linked from the Changelog

           

          Oleg Nenashev added a comment - Ugh, this ticket is linked from the Changelog  

            Unassigned Unassigned
            cesarsotovalero César Soto Valero
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: