[JENKINS-27993] Return useful plugin data from /pluginManager/api/json

[umbertocicciaa]

Return useful data from /pluginManager/api/json by default

Increase @exported visibility to 2 on PluginWrapper's shortName, url, version, active, enabled, and hasUpdate, and export displayName (the non-deprecated replacement for getLongName()), so these fields are no longer dropped when nested under PluginManager.plugins at the API's default depth.

Fixes #21047

Testing done

Added PluginManagerTest#pluginManagerApiJsonReturnsPluginDetails, which installs htmlpublisher.jpi, hits pluginManager/api/json with no depth parameter, and asserts that shortName, version, displayName, active, enabled, and hasUpdate are all present and non-null on the returned plugin object. The test fails against the pre-patch code (all of those fields are absent/empty at default depth) and passes after the @Exported(visibility = 2) changes.

Screenshots (UI changes only)

Before

After

Proposed changelog entries

• Return shortName, url, version, displayName, active, enabled, and hasUpdate in /pluginManager/api/json at the default depth

Proposed changelog category

/label rfe

Proposed upgrade guidelines

N/A

Submitter checklist

• The 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.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, 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

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

Maintainer checklist

• 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, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[Copilot]

Pull request overview

This PR addresses JENKINS-27993 by making /pluginManager/api/json return meaningful plugin information at the default API depth, instead of a list of mostly empty plugin objects. It does so by increasing the @Exported visibility of key PluginWrapper properties so they are retained when serialized under PluginManager.plugins.

Changes:

• Increase @Exported visibility to 2 for key PluginWrapper fields (shortName, url, version, active, enabled, hasUpdate).
• Export displayName (via getDisplayName()) at visibility 2 to provide a non-deprecated name in nested plugin output.
• Add a regression test validating that /pluginManager/api/json includes key plugin fields at default depth.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
core/src/main/java/hudson/PluginWrapper.java	Raises export visibility of commonly needed plugin fields so they appear in /pluginManager/api/json at default depth; also exports displayName.
test/src/test/java/hudson/PluginManagerTest.java	Adds a regression test asserting key plugin properties are present in the /pluginManager/api/json response.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[umbertocicciaa]

Hi @MarkEWaite : ) would you prefer that I rebase, or are there any other best practices you typically follow for this repository?

[MarkEWaite]

Hi @MarkEWaite : ) would you prefer that I rebase, or are there any other best practices you typically follow for this repository?

Please don't rebase. When a pull request is rebased, it risks breaking the association between review comments and the code. We squash merge most pull requests, so there is generally very little benefit from a rebase.

Wait patiently while the review process proceeds.

Consider the GitHub Copilot review comments carefully. It is not a perfect code reviewer, but it is quite good.

[umbertocicciaa]

Hi @MarkEWaite : ) would you prefer that I rebase, or are there any other best practices you typically follow for this repository?

Please don't rebase. When a pull request is rebased, it risks breaking the association between review comments and the code. We squash merge most pull requests, so there is generally very little benefit from a rebase.

Wait patiently while the review process proceeds.

Consider the GitHub Copilot review comments carefully. It is not a perfect code reviewer, but it is quite good.

Thanks a lot for the advice and for sharing your experience maintaining the repository, it’s really helpful :)