* [FIXED JENKINS-41684] Ensure that PluginManager.dynamicLoad runs as SYSTEM.
Test plugin source:
package test;
import hudson.Plugin;
import jenkins.model.Jenkins;
public class ThePlugin extends Plugin {
@Override
public void postInitialize() throws Exception {
Jenkins.getInstance().checkPermission(Jenkins.ADMINISTER);
}
}
* @daniel-beck wants this all reindented.
* [JENKINS-37332] - Improve diagnostics of non-closed streams during reading of the manifests in PluginManager
* [JENKINS-37332] - Leakless processing of JarUrlConnection during Manifest parsing
* [JENKINS-37332] - Also implement leak-safe method for retrieving file modification date
* [JENKINS-37332] - Add spotcheck methods for manifest file access + Javadoc
* [JENKINS-37332] - Also test multi-line and empty attributes in the test
* Check that dependencies are enabled. A disabled optional dependency
will not prevent a plugin from loading.
* Check versions of dependencies declared by a plugin before loading it.
If any dependency (even optional) is older than what is required,
then the plugin isn't loaded.
This should prevent use cases where a plugin is loaded but one of its
dependencies is too old so that :
* its @Extension annotated classes cannot be loaded, causing the full
Jenkins to blow up with crapload of exceptions which are tedious to
investigate to understand the root cause.
* NoSuchMethodError and the likes at runtime even though boot has
completed.
Version check (for setups where version list is manually crafted but yet
works) can be disabled by starting Jenkins with
-Dhudson.PluginWrapper.dependenciesVersionCheck.enabled=true
Minor fixes done while implementing this change :
* Fix version parsing in PluginWrapper.Dependency
* Dynamic plugin load didn't check for disabled flag
* [JENKINS-36666] Properly report the reason for a failed call to Task.getDisplayName.
* [JENKINS-36666] Even without passing fatal=false to @Initializer, recover gracefully from a LinkageError in a task.
* Comment.
Add Upgrade Wizard
Add 'replace' handlebars method in jenkins.js
Fix state transitions to follow a single basic pattern
Suggested plugins selected by default
Add an install state for INITIAL_SECURITY_SETUP
Removed duplicate setupWizard.js on page [FIX JENKINS-34676]
Exclude plugins which are already installed when determining platform
Change 'snooze' to not look like a 'close' button
Make sure unlock screen doesn't show up after new install
Add compatibility check when offering suggested plugins
More appropriate handling of security token filter
* [JENKINS-34745] - Prevent CheckUpdates PeriodicWork death in the case of the missing update site signature
* [JENKINS-34745] - Fix typo in the validator
* [JENKINS-34745] - Fix the formatting of the validation message (cc @lanwen)
required dependencies; this may still have some issues in unknown cases
such as a plugin disabled, then re-enabled without restarting Jenkins
but it fixes one of the primary cases
crash/restart during install may result in installer not completed,
ensure the user may not get locked out if they've created an admin user
but not completed the installer
* Check that dependencies are enabled. A disabled optional dependency
will not prevent a plugin from loading.
* Check versions of dependencies declared by a plugin before loading it.
If any dependency (even optional) is older than what is required,
then the plugin isn't loaded.
This should prevent use cases where a plugin is loaded but one of its
dependencies is too old so that :
* its @Extension annotated classes cannot be loaded, causing the full
Jenkins to blow up with crapload of exceptions which are tedious to
investigate to understand the root cause.
* NoSuchMethodError and the likes at runtime even though boot has
completed.
Version check (for setups where version list is manually crafted but yet
works) can be disabled by starting Jenkins with
-Dhudson.PluginWrapper.dependenciesVersionCheck.enabled=true
Minor fixes done while implementing this change :
* Fix version parsing in PluginWrapper.Dependency
* Dynamic plugin load didn't check for disabled flag
As a part of PR 1847, 3b5424e507 introduced a second invocation to
executeReactor. This is causing a problem in that it exectes
InitMilestone progression twice. If you are looking at
Jenkins.getInitLevel() it will go through STARTED ... COMPLETED once,
then it goes back to STARTED and then go to COMPLETED again.
And this code looks bit odd anyway. Why execute a whole reactor
just to make one method invocation? But I didn't see any discussion of
this in PR 1847.
This change fixes this oddity by making this a part of the main
(and sole) initialization reactor session. It's not clear what
milestone should be the pre-requisite, but given that it's only looking
at dependency chain, PLUGINS_PREPARED should be adequate.
Jesse Glick