* Do not warn repeatedly of the same missing update site dependency.
This happens when locally testing split plugins (despite their presence in WEB-INF/detached-plugins/*.hpi).
(cherry picked from commit 918a0fd221)
* Detached plugins must be kept up to date with security advisories.
(cherry picked from commit e08d28a698)
* Load detached plugins which are implicit dependencies of other plugins at startup, even if the update center was not used.
(cherry picked from commit ad7a36001d)
* Adjusted expected version after e08d28a698.
(cherry picked from commit 84f939cebd)
* e08d28a698 exposed tests which had been incorrectly storing plugins as *.hpi rather than *.jpi.
(cherry picked from commit a0abad7ec4)
* Test failure after ad7a36001d.
(cherry picked from commit 0084e8dbdd)
* Another test failure after ad7a36001d30a6174b25e616fc3c215dd24919d1; fewer installDetachedPlugin calls are now required.
(cherry picked from commit b65bb54e99)
* Move detached plugins logic into a dedicated class
ClassicPluginStrategy is already long enough, so trying to make things a
bit more focused before adding Java 11 logic. (and even if not, the change
still splits a class that is almost 1k lines).
* Install jaxb as detached only on Java 11+
* Remove duplicate @Restricted
Given the enclosing class already has it.
* Use 1.5 release
* Add more test coverage
* getMinJavaVersion => getMinimumJavaVersion
* Rename DetachedPluginsManager as DetachedPluginsUtil
as requested by Oleg and Jesse. Mainly because of the misleading
relationship (there's no inheritance) with the existing `PluginManager`
class.
* 🤦 adjust to 1.5 release method renaming
* Clarify minimum Java version column
Co-Authored-By: batmat <bmathus@gmail.com>
* Update to 2.3.0 version of the jaxb plugin
* Bump minimum core version to next expected release version
* Add preventive cycle breaks for jaxb while waiting for JENKINS-28942
As requested by Oleg.
* Add test to fail fast on wrong format for split-plugins.txt
* [FIXED JENKINS-44898] Add findResource to PluginFirstClassLoader
This fixes GroovyClassLoader.loadClass for a .groovy file in a plugin
with a PluginFirstClassLoader, specifically by fixing fast-loading via
the UberClassLoader.
* Move common code to AntWithFindResourceClassLoader.
* Adding testing of new PluginFirstClassLoader behavior.
* Do not load detached plugins during tests.
Also warn about plugins which force us to create classes.jar.
* Porting POM fix from #2795: we must allow snapshots from repo.jenkins-ci.org so as to be able to test upstream component PRs.
* Fixed failures in tests which assumed detached plugins were being loaded.
* jenkins-test-harness 2.20
* Unreproducible test failure on CI, probably due to timing.
- 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
- This really has to be controlled by either a system property or a CLI parameter as we cannot guarantee that any path
specified in a configuration file in JENKINS_HOME will be valid on another machine where the JENKINS_HOME is mounted
- Obviously Jenkins does not currently support fully starting two Jenkins instances on the same JENKINS_HOME, so this
fix is to assist in Disaster Recovery (or semi-higher availability) sceanarios where the backup node is being brought
up. In such cases, the node that failed may not have correctly released all its file handles in the backing NFS share
and thus could be blocking the recovery node from starting up.
- An additional use case is where the JENKINS_HOME is stored on a remote disk, e.g. a SAN, etc. and the user wants to
take advantage of the faster local disk to serve the resources from both plugins and Jenkins core. Without this change
only Jenkins core can be relocated outside of JENKINS_HOME (using the '--webroot=...' command line option).
- Ideally we would introduce this into the extras-executable-war module once the system property has had time to soak
(although in an ideal world that module would be agnostic of Jenkins and thus it might not be appropriate there)
Accomplished by centralizing calls to System.getProperty(String) and related into new file SystemProperties.java.
There, we first check for existence of system property; if not, we look for property in context.xml
This is done for "application" properties (like hudson.DNSMultiCast.disabled) but not for java properties (like user.name)
The new version of the BCT does not generate stackMap if the original code
did not contain stack maps. Further more the new version takes a
classloader to use so that it can load classes when searching for the
common parent class.
Reproducible for example via HelpLinkTest.testMatrixConfig.
Otherwise have: matrix-project → script-security → matrix-auth → windows-slaves → antisamy-markup-formatter → matrix-project
Tried to come up with a generic way of doing this automatically, but failed.
Just because we bundle a particular build of some plugin does not mean it was built against anything recent,
and for use on older cores it may well need some of those implicit dependencies.
Basil Crow