Remove dependency on jenkins-js-modules

[basil]

Problem

The jenkins-js-modules dependency is a custom in-house library developed to load JavaScript and CSS from the client side. This is a source of significant complexity and has not been updated since 2016. This dependency is a liability.

Solution

Rewrite usages of <l:css> and <l:js> without this dependency and remove these tags from the layout library.

In core, usages were limited to the new job page, the plugin manager, and the system information page.

In plugins this is only used by dependency-track-plugin and servicenow-cicd-plugin (and referenced from design-library-plugin). Once this PR is approved, I will file PRs to update all three and wait for at least dependency-track-plugin and design-library-plugin to be released before this PR is merged.

Implementation

Rewrote this client-side behavior to be server-side by adding the relevant tags to the Jelly files corresponding to the dynamically generated tags from before. Since the dynamic generation had deduplication logic, I ensured the statically generated versions were also always present at most one time by adding them to the top-most level of Jelly files, the same level that invokes l:layout.

Testing done

Went to the new job page, the plugin manager, and the system information page. Exercised the relevant functionality and stepped through the code in the debugger to make sure the scripts were still being executed. Verified in the browser tools that the relevant CSS was still being loaded.

Proposed changelog entries

Simplify loading of JavaScript and CSS. Users of OWASP Dependency-Track must upgrade to 4.3.1 or later, and users of ServiceNow CI/CD must upgrade to 2.1 or later.

Proposed upgrade guidelines

Simplify loading of JavaScript and CSS. Users of OWASP Dependency-Track must upgrade to 4.3.1 or later, and users of ServiceNow CI/CD must upgrade to 2.1 or later.

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Maintainer checklist

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

• There are at least two (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 is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see 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).

[NotMyFault]

Oh, that's nice. Thanks for taking care of the steps to get a rid of jenkins-js-modules 👍

[basil]

All downstream PRs have been merged. Still waiting on a release of Design Library and OWASP Dependency-Track.

[NotMyFault]

All downstream PRs have been merged. Still waiting on a release of Design Library and OWASP Dependency-Track.

Design library has been released.

[sephiroth-j]

OWASP Dependency-Track as well.

[basil]

Thank you! I updated the text of the release notes and upgrade guide to mention the specific versions that were just released. From my perspective this PR is ready.

[NotMyFault]

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!

[NotMyFault]

Thoughts on archiving the jenkins-js-modules repository, or at least putting a note in place outlining that it's no longer maintained?

[basil]

Yeah, core is no longer using this subsystem, and any plugins that are still using it are either suspended or deprecated, so I would think we could archive all three of these:

https://github.com/jenkinsci/js-libs
https://github.com/jenkinsci/js-modules
https://github.com/jenkinsci/js-samples