Add non-deprecated Jenkins core library dependencies to the BOM

[oleg-nenashev]

There are Jenkins-based components like Jenkinsfile runner or Custom WAR Packager which repackage the Jenkins core and add custom libraries. There is a hsistory of non-trivial breakages there caused by using wrong library versions, jenkinsci/jenkinsfile-runner#272 is a recent example for version-number.

This patch adds non-deprecated libraries from the Jenkins core into the Bill of Materials.

Proposed changelog entries

• Add non-deprecated Jenkins core library dependencies to the BOM
• ...

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[jtnord]

I hesitated about this.

The addition of common libraries such as commons-* (which where missed due to an oversight on my part) is fine, but the others I am not so sure about.

Whilst I understand the desire from JenkinsFileRunner - this does make it even easier to depend on things that perhaps you shouldn't be depending on inside plugins that would make a future cleanup (yes I still have hope of that happening) much harder.

Especially for the likes of something that could become a detached plugin (icon-shim has been excluded here to prevent a recursion of sorts (which should actually be ok as Maven breaks recursion and has ITs for it).

[jtnord]

thanks for adding the commons-* it was on my TODO to add them - no idea why I missed them in the first round :-(

[jtnord]

sounds perfect for a detached plugin?

[daniel-beck]

Will this affect our ability to upgrade, downgrade, or remove any of these libraries from Jenkins, and if so, how?

[oleg-nenashev]

Will this affect our ability to upgrade, downgrade, or remove any of these libraries from Jenkins, and if so, how?

It will not. BOM just reflects the current state of included dependencies, it does not provide any new guarantees to users. Indeed it may cause build failures for users who depend on a core library that gets removed, but IMHO such failure is much better that the silent "okay" as it would happen now.

I also skipped the most creepy libs which we would like to remove eventually

[daniel-beck]

🤷 Don't understand this space well enough to approve; but am not rejecting either.

[oleg-nenashev]

I plan to merge it in 24 hours if no negative feedback. Please see the merge process documentation for more information