Message Title
| |
|
|
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.
|
|
|
|
| |
|
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203334.1574985449000.10213.1575304200407%40Atlassian.JIRA.
Locked
