[JENKINS-60326] Remove unused dependencies from Jenkins CLI #20730

Activity

1. jenkins-infra-bot commented on Dec 1, 2019

   

   jenkins-infra-bot

   on Dec 1, 2019

   Author

   More actions

   markewaite:

   • Original comment link
   • Raw content of original 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.
     

   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.
2. jenkins-infra-bot commented on Dec 2, 2019

   

   jenkins-infra-bot

   on Dec 2, 2019

   Author

   More actions

   cesarsotovalero:

   • Original comment link
   • Raw content of original comment:

     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.
     
      
     

   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.

    
3. jenkins-infra-bot commented on Jan 24, 2020

   

   jenkins-infra-bot

   on Jan 24, 2020

   Author

   More actions

   oleg_nenashev:

   • Original comment link
   • Raw content of original comment:

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

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

    
4. jenkins-infra-bot commented on Jan 24, 2020

   

   jenkins-infra-bot

   on Jan 24, 2020

   Author

   More actions

   oleg_nenashev:

   • Original comment link
   • Raw content of original comment:

     Ugh, this ticket is linked from the Changelog
     
      
     

   Ugh, this ticket is linked from the Changelog

    
5. jenkins-infra-bot

   added

   imported-jira-issue

   priority:minor

   resolution:unresolved

   enhancement

   component:cli

   on Nov 24, 2025