• 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

          César Soto Valero created issue -

          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 made changes -
          Description Original: Hello, I noticed that the dependency org.jvnet.hudson:jtidy is declared in module core. 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] , 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 core and therefore they can be excluded from 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.
          New: 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.
          César Soto Valero made changes -
          Description Original: 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.
          New: 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|http://example.com]|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.
          César Soto Valero made changes -
          Description Original: 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|http://example.com]|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.
          New: 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|http://example.com]] , 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.

          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 made changes -
          Summary Original: Remove unused dependencies New: Remove unused dependencies from Jenkins CLI
          Oleg Nenashev made changes -
          Component/s Original: core [ 15593 ]
          Oleg Nenashev made changes -
          Summary Original: Remove unused dependencies from Jenkins CLI New: Remove unused dependencies from Jenkins Core
          Oleg Nenashev made changes -
          Component/s New: core [ 15593 ]
          Component/s Original: cli [ 15624 ]

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

              Created:
              Updated: