* [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.
Of course the import being used is in a package name that is reserved for artifacts produced by a JSR... and the JSR that the dependency is claiming to come from has not actually published anything... thus whoever produced the artifact has broken the JSR policy... and it is also not safe for us to actually use these annotations as we do not know what a JSR may change on the road to actually providing this... but that is a war for a different PR
- Also expose via servlet context parameter of same name to allow multiple instances of Jenkins in the same servlet container to have different directories
- As we are no longer a constant, change the system property to camelCase
Stephen Connolly