jenkinsci / plugin-pom

Parent POM for Jenkins Plugins

Parent POM for Jenkins Plugins

Introduction

The plugin parent POM is decoupled from the core Jenkins project, both from a Maven perspective and a repository perspective. It provides a common build configuration for all Jenkins plugins.

Requirements

Since version 4.52, the plugin parent POM requires Jenkins 2.361 or newer and JDK 11 or newer. Since version 4.40, the plugin parent POM supports Java 17.

Usage

To use the plugin parent POM, change the parent POM of your plugin:

  <parent>
    <groupId>org.jenkins-ci.plugins</groupId>
    <artifactId>plugin</artifactId>
    <version>VERSION</version> <!-- See https://github.com/jenkinsci/plugin-pom/releases for available versions-->
    <relativePath />
  </parent>

Then override the needed properties, e.g.:

  <properties>
    <!--
    Take a look the developer documentation for the baseline version to use
    https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/#currently-recommended-versions
    -->
    <jenkins.version>2.361.4</jenkins.version>
  </properties>

If you have a jar:test-jar execution, delete it and add the following to <properties>:

<no-test-jar>false</no-test-jar>

Overridable properties

The following properties are overridable:

• jenkins.version: The Jenkins version required by the plugin. Mandatory. See Requirements for more info. Being able to specify the jenkins.version simplifies testing the plugin with different core versions, which is important (among other reasons) for Plugin Compatibility Testing (PCT).
• jenkins-test-harness.version: The JTH version used to test plugin. Uses split test-harness (see JENKINS-32478).
• hpi-plugin.version: The HPI Maven Plugin version used by the plugin. (Generally you should not set this to a version lower than that specified in the plugin parent POM.)
• stapler-maven-plugin.version: The Stapler Maven plugin version required by the plugin.
• In order to make their versions the same as the used core version, node.version and npm.version properties are provided.

Incrementals

You can configure your plugin to treat every commit as a release candidate. See Incrementals for details.

Formatting

To opt in to code formatting of your Java sources and Maven POM with Spotless, define the spotless.check.skip property to false and remove any existing Spotless configuration from your POM.

To format existing code, run:

mvn spotless:apply

After formatting an existing repository, squash merge the PR and create a .git-blame-ignore-revs file to hide the formatting commit from blame tools.

Running Benchmarks

To run JMH benchmarks from JUnit tests, you must run you must activate the benchmark profile. For example:

mvn -P jmh-benchmark test

When the jmh-benchmark profile is enabled, no tests apart from JMH benchmarks will be run. The names of the classes containing the benchmark runners should either begin with or end with the word Benchmark. For example, FooBenchmark and BenchmarkFoo will be detected when using -Dbenchmark, however, FooBar will be ignored.

See also: documentation for JMH benchmarks

Javadoc

Javadoc has been set to quiet by default in 2.20+, which means it will only log errors and warnings. If you really want it verbose, set quiet property to false for the plugin.

Releasing

Tests are skipped during the perform phase of a release. This can be overridden by setting release.skipTests to false.

Setup Wizard

By default, the setup wizard (Jenkins >= 2.0) is skipped when using hpi:run. If you want the wizard to be enabled just run:

mvn -Dhudson.Main.development=false hpi:run

Jenkins Core BOM

Since version 2.195, Jenkins provides a Maven Bill Of Materials (BOM) that centrally defines versions of various libraries used by Jenkins Core and should make it easier to update to newer Jenkins Core versions

For more information, see the Dependency Management section of the plugin development guide.

plugin-pom's Issues

Reproducible builds

https://reproducible-builds.org explains the reasons why reproducible builds are desirable. Some known issues related to reproducible builds:

• project.build.outputTimestamp is not configured as recommended in https://maven.apache.org/guides/mini/guide-reproducible-builds.html
• https://maven.apache.org/guides/mini/guide-reproducible-builds.html notes that maven-release-plugin version 3.0.0-M1 or later will automatically update the project.build.outputTimestamp property in pom.xml during the release in the same commit that updates version but that "if you have a custom release process tooling, you'll need to add the feature to your release tooling." https://github.com/jenkinsci/incrementals-tools is missing this feature.
• Use of Properties#store (e.g., in Stapler) adds timestamps to every generated resource file — though perhaps this could be worked around by specifying -Djava.properties.date on recent Java versions or using a custom Writer that chomps comment lines
• JAR and JPI artifacts created by maven-hpi-plugin do not call MavenArchiver#configureReproducibleBuild as recommended in https://s.apache.org/reproducible-builds
• Even with an explicit source and target defined, each major JDK version changes the generated bytecode
• https://maven.apache.org/guides/mini/guide-reproducible-builds.html notes that maven-javadoc-plugin requires <notimestamp>true</notimestamp> configuration in <pluginManagement> for use both from plugins and reports; this may or may not be an issue in Jenkins plugin builds
• Different line breaks on Unix versus Windows systems are a common problem, which may or may not apply to Jenkins plugin builds

There may be additional issues beyond what is listed above. Further investigation is needed to determine how to achieve this goal.

Add `access-modifier-suppressions` by default

What feature do you want to see added?

In both jenkinsci/azure-ad-plugin#550 and jenkinsci/htmlpublisher-plugin#274 plugins wanted to use access-modifier-suppressions but didn't find it working out of the box and added it in a way that bloated the JAR. Since this is a common mistake, it might be helpful for the default plugin build to include this functionality out of the box.

Upstream changes

No response

Are you interested in contributing this feature?

No response

Plugin POM hard-codes EE 8

plugin-pom/pom.xml

Lines 182 to 187 in 8561e2e

	<dependency>
	<!-- used in JTH and jenkins core > 2.x -->
	<groupId>jakarta.servlet</groupId>
	<artifactId>jakarta.servlet-api</artifactId>
	<version>4.0.4</version>
	</dependency>

hard-codes the Servlet API to EE 8 (the last version with javax imports), which means that when core is upgraded to EE 9 and plugins upgrade their core baseline to that version, their tests will start failing, even if they have been otherwise prepared with a test harness that supports both EE 8 and EE 9 (see jenkinsci/jenkins-test-harness#770). This manifests in strange and hard-to-debug errors, like not being able to import jakarta servlet types, or the compatibility methods introduced in jenkinsci/javax-servlet-api#5 not existing (because the wrong javax version of the jakarta.servlet-api takes precedence over the package delivering the compatibility methods).

The ideal solution is to simply delete these lines and let the version be managed by the core (not plugin) BOM, which is possible as of jenkinsci/jenkins#9288; however, it would imply raising the minimum core version supported by this repository to 2.459 or higher, something that is likely too aggressive at this point in time.

Add `-proc:full` to javac args for plugins

At least plugin builds, and probably some other component builds such as core (maybe just do this also in the generic parent POM), should be given the -proc:full argument when this is available (21+?). Otherwise builds may be broken in some future Java version (22?) due to JDK-8306819. See openjdk/jdk#14499 by @jddarcy.

There is some discussion of a bare -proc argument in older versions but I do not see this in the JDK 11 help; it does not appear that there is any argument which can be passed to JDK 11 which will prevent the build from breaking in the future, which seems unfortunate as it would mean that we would need to detect the JDK version with a profile to support building with newer JDKs even when targeting 11 or 17.

Switching to an explicit list of annotation processors would be awkward since there are a bunch of them in the Maven classpath and we do rely on the service detection to run them all. (In fact there is at least one proprietary plugin in CloudBees CI which adds its own, under the expectation that plugins depending on it will automatically run that processor.)

"Parameter `spotbugsXmlOutput` is deprecated: No reason given" warning

Jenkins and plugins versions report

Apache Maven 3.9.0
Java version: 11.0.18, vendor: Ubuntu

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 22.04.2 LTS x86_64

Reproduction steps

Run mvn clean verify in a consumer of this component.

Expected Results

Note: These are the actual results with #700 reverted.

There are no SpotBugs warnings:

[INFO] >>> spotbugs:4.7.3.0:check (spotbugs) > :spotbugs >>>
[INFO] --- spotbugs:4.7.3.0:spotbugs (spotbugs) ---
[INFO] Fork Value is true
[INFO] Done SpotBugs Analysis....
[INFO] <<< spotbugs:4.7.3.0:check (spotbugs) < :spotbugs <<<
[INFO] --- spotbugs:4.7.3.0:check (spotbugs) ---
[INFO] BugInstance size is 0
[INFO] Error size is 0
[INFO] No errors/warnings found

Actual Results

A "Parameter spotbugsXmlOutput is deprecated: No reason given" warning is logged:

[INFO] --- spotbugs:4.7.3.2:spotbugs (spotbugs) ---
[WARNING] Parameter 'spotbugsXmlOutput' is deprecated: No reason given
[INFO] <<< spotbugs:4.7.3.2:check (spotbugs) < :spotbugs <<<
[INFO] --- spotbugs:4.7.3.2:check (spotbugs) ---
[WARNING] Parameter 'spotbugsXmlOutput' is deprecated: No reason given

Anything else?

Caused by #700.

spotless check is run in quick-build

Jenkins and plugins versions report

`mvn verify -Pquick-build` still runs spotless

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: c:\java\maven-3.9.1
Java version: 11.0.15, vendor: Eclipse Adoptium, runtime: c:\java\jdk-11.0.15+10
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

due to the activation of spotless in children of the the quick-build profile setting of spotless.check.skip is ignored as the child modules opting into spotless override this behaviour.

Observed in plugin-compat-tester

What Operating System are you using (both controller, and any agents involved in the problem)?

Windows

Reproduction steps

1. introduce some violation in a downstream plugin of this project that has spotless enabled (e.g. insert some extra tabs instead of spaces in java source code of https://github.com/jenkinsci/plugin-compat-tester)
2. run mvn -Pquick-build verify

Expected Results

the build completes and a jar file exists in target

Actual Results

the build fails as spotless has detected errors

Anything else?

see jenkinsci/pom#425 for exactly the same issue

published incremental poms have dependencyManagement stripped causing incorrect dependency resolution

Jenkins and plugins versions report

Environment

ci.jenkins.io - N/A

A plugin that is using incrementals/CD publishing has its pom mangled by the maven-flatten-plugin

this flattening removes the dependencyManagement entries as can be seen between this repository file and this published artifact

As the dependencies on kotlin are transitive they are not included in the flattened pom, but are included in the hpi.

when the plugin is depended on by another plugin the result is the dependency manamgemtn is gone so you get the transitive version of the dependencies, not the version that the plugin was built with and bundled.

This not only causes errors for consumers - it also makes the behaviour of a build different in your IDE than when deployed - as in the IDE with workspace resolution the dependencies would be correct, but once released or in CI they would be different.

Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.10 paths to dependency are:
+-org.jenkins-ci.plugins:github-api:1.303-999999-SNAPSHOT
ohttp-api-plugin --->    +-io.jenkins.plugins:okhttp-api:4.10.0-125.v3593b_a_f8c97b_
  +-com.squareup.okhttp3:logging-interceptor:4.10.0
    +-org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.10
and
+-org.jenkins-ci.plugins:github-api:1.303-999999-SNAPSHOT
ohttp-api-plugin --->  +-io.jenkins.plugins:okhttp-api:4.10.0-125.v3593b_a_f8c97b_
  +-com.squareup.okio:okio:3.3.0
    +-com.squareup.okio:okio-jvm:3.3.0
      +-org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.0
]

jenkinsci/github-api-plugin#200 (review)

What Operating System are you using (both controller, and any agents involved in the problem)?

N/A

Reproduction steps

jenkinsci/github-api-plugin#200 (review)

Expected Results

no enforcer error - dependency:tree would show the same versions of kotlin both in the okhttp-api plugin and in any other consumer of it that does not itself depend on kotlin

Actual Results

dependencyManagement is stripped, downstream consumers get incorrect library versions.

Anything else?

No response

maven-enforcer-plugin reports missing dependencies on latest POM / BOM

Jenkins and plugins versions report

Environment

BOM: 1508.v4b_d09ff0e893
POM: 4.43.1 (latest)
Jenkins: A LTS listed in BOM

What Operating System are you using (both controller, and any agents involved in the problem)?

• Linux / Windows (Jenkins CI)
• Linux (local)

Reproduction steps

1. Update BOM or POM to latest versions (see examples below)
2. Build the project
3. Warnings appear

Expected Results

No missing dependencies / warnings

Actual Results

Warnings are issued for missing dependencies

Example:

[WARNING] Missing:
----------
1) org.jenkins-ci.plugins.workflow:workflow-step-api:jar:625.vd896b_f445a_f8

  Try downloading the file manually from the project website.

  Then, install it using the command: 
      mvn install:install-file -DgroupId=org.jenkins-ci.plugins.workflow -DartifactId=workflow-step-api -Dversion=625.vd896b_f445a_f8 -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
      mvn deploy:deploy-file -DgroupId=org.jenkins-ci.plugins.workflow -DartifactId=workflow-step-api -Dversion=625.vd896b_f445a_f8 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
  	1) org.jenkins-ci.plugins.workflow:workflow-step-api:jar:625.vd896b_f445a_f8

----------
1 required artifact is missing.

for artifact: 
  org.jenkins-ci.plugins.workflow:workflow-step-api:jar:625.vd896b_f445a_f8

from the specified remote repositories:
  central (https://repo.maven.apache.org/maven2, releases=true, snapshots=false)
Path to dependency: 
	1) org.jenkins-ci.plugins.workflow:workflow-step-api:jar:625.vd896b_f445a_f8

Anything else?

Examples:

• jenkinsci/webhook-step-plugin#114
• jenkinsci/credentials-plugin#342

non repeatable builds where node is used

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

N/A

Reproduction steps

1. clone a project that is using some node modules as part of its builds
2. build the project (inspect the package-lock.json file and archive it
3. wait an amount of time for newer packages to be available
4. clean the project (git clean -fdx)
5. build the project
   6 compare the 2 package-lock.json files

Expected Results

they are identical, any build can be cloned from SCM and the rebuilt by using defined versions of dependencies

Actual Results

there are changes. builds in CI and locally use the latest that they resolve

Anything else?

the build is using npm install and not npm ci

the pom should be configured to use npm ci by default and if/when things are updated a developer should run npm install locally and then commit the changes to the package-lock.json

see jenkinsci/bom#2121 (comment) and jenkinsci/bootstrap5-api-plugin#220

`yarn mvntest` failures ignored in CI

In jenkinsci/workflow-cps-plugin#821 I struggled to figure out how this ever passed in CI. Turns out

mvn verify -Dtest=InjectedTest -Dmaven.test.failure.ignore

prints ESLint failures but passes anyway. https://github.com/eirslett/frontend-maven-plugin#ignoring-failure does not say where test failures would be recorded. Based on inspecting sources, they are not recorded anywhere at all, so using junit is not enough. I think this mojo parameter needs to be disabled in the POM so that maven.test.failure.ignore applies only to Surefire.

regression in IntelliJ support

Jenkins and plugins versions report

WHen running a plugins unit test in intellij this no longer works out of the box with the plugin-pom 4.40 or higher.

This is in #524 the argLine was updated to use a surefire differed property, but IntelliJ does not support this in the default config.

Workaround is to not get surefire to parse the argline, however this does mean the the unit test can be run differently in the IDE than from maven due to different JVM settings.

IntelliJ / plugin using plugin pom 4.40 or higher

What Operating System are you using (both controller, and any agents involved in the problem)?

N/A

Reproduction steps

in a clean intellij environment clone a plugin using plugin pom 4.40 or higher.

Select a unit test and run it

Expected Results

intellij can not launch the test

Actual Results

intellij launches the test and provides the result (this is the behaviour using a parent prior to 4.40)

Anything else?

this is an intellij bug, but more people seem to use intellij than eclipse (or other IDEs) so we may want to rework how we do the java module confuguration.

Remove `provided` dependency on `commons-logging`

The provided dependency on commons-logging is inconsistent with the general design of this POM, which avoids specifying Jenkins core dependencies in order to allow them to be fetched from the Jenkins core BOM.

For a comprehensive fix, the provided dependency should be removed both from here and from Jenkins core. The main implementation/testing challenge here is to avoid a regression with regard to https://www.slf4j.org/codes.html#release

The relevant test scenarios are:

1. Jenkins core before the change to remove commons-logging, plugin POM before the change to remove commons-logging (the status quo)
2. Jenkins core before the change to remove commons-logging, plugin POM after the change to remove commons-logging (the scenario when a plugin updates its parent POM but not its core)
3. Jenkins core after the change to remove commons-logging, plugin POM before the change to remove commons-logging (the scenario when a plugin updates its core but not its parent POM)
4. Jenkins core after the change to remove commons-logging, plugin POM after the change to remove commons-logging (the scenario when a plugin updates both its core and its parent POM)

A test scenario should be set up to expose https://www.slf4j.org/codes.html#release in both core and a plugin, and the results of (1) in both scenarios should be measured to establish a baseline. Then (2), (3), and (4) should also be measured in all applicable scenarios to assure there are no regressions.

Add Javadoc links to commonly depended-on plugins

plugin-pom/pom.xml

Lines 360 to 362 in 91ff1d2

	<links>
	<link>https://javadoc.jenkins.io/</link>
	</links>

It would be nice if commonly depended on plugins providing types exposed through dependent plugins (cloudbees-folder, branch-api, scm-api, git, etc.; mailer and matrix-auth probably not because of packages shared with core?) would have their Javadoc URLs added here so references between plugins' Javadoc sites work.

Also Stapler to have links to the various types (e.g. StaplerProxy).

Thoughts?

release notes for 4.64 hamcrest upgrade is wrong

Jenkins and plugins versions report

https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.64 states

imports containing org.hamcrest.CoreMatchers.; should be migrated to org.hamcrest.Matchers..

this is incorrect - the code is in no way deprecated.

as per jenkinsci/acceptance-test-harness#1190 (comment)

The methods don't have a dedicated deprecation annotation (yet?) because they have been copied into hamcrest. I assume because the entire module they are at is deprecated.

but that's the pom.

the hamcrest artifact itself contains both org.hamcrest.Matchers and org.hamcrest.CoreMatchers as well as all the other classes.

And the source tree is equally just deprecating the artifact which contains only a single class and all classes remain in org.hamcrest:hamcrestnot any classes?

There is no need to change any code other than changing the pom import.

What Operating System are you using (both controller, and any agents involved in the problem)?

N/A

Reproduction steps

go to https://github.com/jenkinsci/pom/releases/tag/jenkins-1.99 and read

Expected Results

release notes do not mention changing imports or classes

Actual Results

release notes say you have extra work to do

Anything else?

See also jenkinsci/pom#447

Integrate OpenRewrite

https://github.com/openrewrite/rewrite-jenkins looks like a good place to keep rules for updating Jenkins plugin (also see openrewrite/rewrite-jenkins#6). Yet https://docs.openrewrite.org/running-recipes/getting-started#step-2-add-rewrite-maven-plugin-or-rewrite-gradle-plugin-to-your-project and https://docs.openrewrite.org/running-recipes/getting-started#step-3-activate-a-recipe indicate that it is not ready to run out of the box. It would be great if any plugin using a sufficiently new parent were preconfigured to activate all relevant recipes so you could

mvn rewrite:run

without further ado.

(Of course there is a minor “chicken-and-egg” issue that in order to get access to https://github.com/openrewrite/rewrite-jenkins/blob/c15eac724e2c66ff956926f5966177995f035472/src/main/resources/META-INF/rewrite/rewrite.yml#L24C1-L28 you would first need to manually update your parent, but I think that is acceptable.)

Possibly depends on openrewrite/rewrite-jenkins#4 (@sghill).

Goal `display-info` is deprecated on `maven-enforcer-plugin`

What feature do you want to see added?

Hi,

This goal has been deprecated on the maven-enforcer-plugin (https://maven.apache.org/enforcer/maven-enforcer-plugin/display-info-mojo.html)

It raise the warning during build

Caused by #689

[WARNING] Goal 'display-info' is deprecated: please use mvn --version

Not sure if it should be simply removed or replaced by something else.

Regards,

Upstream changes

No response

Remove `<mavenExecutorId>forked-path</mavenExecutorId>`?

We don't customize this in jenkinsci/pom, and automated release of both Jenkins core and core components seem to work fine without it, as do manual releases with maven-release-plugin. Seems more straightforward to me to get rid of this customization and follow a more standard code path that is in line with Maven defaults. I was unable to find any commit messages or tickets that explain the reason why this was customized to begin with.

Run `bridge-method-injector` by default

What feature do you want to see added?

jenkinsci/htmlpublisher-plugin#273 shows a plugin that used the @WithBridgeMethods to no avail because the build was never running bridge-method-injector. Rather than forcing every plugin that wants to use this annotation to add bridge-method-injector to its build, it seems desirable to run bridge-method-injector by default for all plugin builds.

Upstream changes

No response

Are you interested in contributing this feature?

No response

Remove ASM workaround

When ASM is removed from Jenkins core and this change has propagated through a sufficient number of LTS releases, the workaround added in #916 can be removed.

Enforce set of transitive deps

(split from #705 (comment))

As of jenkinsci/maven-hpi-plugin#130 if your plugin bundles some library which has transitive deps, you get a warning in the build log alerting you to possibly unintentional elements, but who looks at that? Would be better to mechanically enforce the set. This would be incompatible, so it has to be as easy as possible to adapt. For example

[INFO] --- maven-hpi-plugin:3.38:hpi (default-hpi) @ artifact-manager-s3 ---
[INFO] Generating …/artifact-manager-s3-plugin/target/artifact-manager-s3/META-INF/MANIFEST.MF
[INFO] Checking for attached .jar artifact ...
[INFO] Generating jar …/artifact-manager-s3-plugin/target/artifact-manager-s3.jar
[INFO] Building jar: …/artifact-manager-s3-plugin/target/artifact-manager-s3.jar
[INFO] Exploding webapp...
[INFO] Copy webapp webResources to …/artifact-manager-s3-plugin/target/artifact-manager-s3
[INFO] Assembling webapp artifact-manager-s3 in …/artifact-manager-s3-plugin/target/artifact-manager-s3
[WARN] Bundling transitive dependency gson-2.8.9.jar (via aws-s3)
[WARN] Bundling transitive dependency guice-assistedinject-5.0.1.jar (via aws-s3)
[WARN] Bundling transitive dependency commons-io-2.11.0.jar (via tika-core)
[WARN] Bundling transitive dependency javax.ws.rs-api-2.0.1.jar (via aws-s3)
[WARN] Bundling transitive dependency s3-2.5.0.jar (via aws-s3)
[WARN] Bundling transitive dependency sts-2.5.0.jar (via aws-s3)
[INFO] Bundling direct dependency aws-s3-2.5.0.jar
[WARN] Bundling transitive dependency jclouds-blobstore-2.5.0.jar (via aws-s3)
[WARN] Bundling transitive dependency jclouds-core-2.5.0.jar (via aws-s3)
[INFO] Bundling direct dependency tika-core-2.7.0.jar
[INFO] Generating hpi …/artifact-manager-s3-plugin/target/artifact-manager-s3.hpi
[INFO] Building jar: …/artifact-manager-s3-plugin/target/artifact-manager-s3.hpi

could be replaced by INFO messages if you were required to also add one thing to properties like

<hpi.transitive.deps>commons-io gson guice-assistedinject javax.ws.rs-api jclouds-blobstore jclouds-core s3 sts</hpi.transitive.deps>

and the failing build prompted you to add that.

Subsequently, if some Dependabot update caused the set of transitive dependencies to grow or shrink, that PR build would fail until you edited the line, signaling your approval of the change.

Missing artifact in jenkins repo for jenkins-war executable-war type since 2.30.

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Fedora 38
Linux f38lite 6.8.9-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 2 18:50:49 UTC 2024 x86_64 GNU/Linux

Reproduction steps

clone https://github.com/whitingjr/horreum-plugin/tree/horreum-plugin-version-bump-horreum-to-0.14
mvn test -Dtest=HorreumUploadStepTest#testUploadMultiple

Expected Results

The test is started using the plugin project. All artifacts in the plugin pom can be resolved.

Actual Results

Downloading from repo.jenkins-ci.org: https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.440.3/jenkins-war-2.440.3.executable-war
Downloading from central: https://repo1.maven.org/maven2/org/jenkins-ci/main/jenkins-war/2.440.3/jenkins-war-2.440.3.executable-war
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.741 s <<< FAILURE! - in jenkins.plugins.horreum.HorreumUploadStepTest
[ERROR] jenkins.plugins.horreum.HorreumUploadStepTest.testUploadMultiple Time elapsed: 0.008 s <<< ERROR!
java.lang.RuntimeException: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for io.jenkins.plugins:horreum::hpi:0.1.5-SNAPSHOTnull
at io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:643)
at io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:727)
at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestClassConstructor(InvocationInterceptor.java:73)
at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:62)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeTestClassConstructor(ClassBasedTestDescriptor.java:363)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.instantiateTestClass(ClassBasedTestDescriptor.java:310)
at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.instantiateTestClass(ClassTestDescriptor.java:79)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.instantiateAndPostProcessTestInstance(ClassBasedTestDescriptor.java:286)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$testInstancesProvider$4(ClassBasedTestDescriptor.java:278)
at java.base/java.util.Optional.orElseGet(Optional.java:364)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$testInstancesProvider$5(ClassBasedTestDescriptor.java:277)
at org.junit.jupiter.engine.execution.TestInstancesProvider.getTestInstances(TestInstancesProvider.java:31)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$prepare$0(TestMethodTestDescriptor.java:105)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.prepare(TestMethodTestDescriptor.java:104)
at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.prepare(TestMethodTestDescriptor.java:68)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$prepare$2(NodeTestTask.java:123)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.prepare(NodeTestTask.java:123)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:90)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:35)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:54)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:147)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:127)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:90)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:55)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:102)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:54)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:86)
at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:86)
at org.apache.maven.surefire.junitplatform.LazyLauncher.execute(LazyLauncher.java:55)
at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.execute(JUnitPlatformProvider.java:223)
at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invokeAllTests(JUnitPlatformProvider.java:175)
at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:139)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
Caused by: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for io.jenkins.plugins:horreum::hpi:0.1.5-SNAPSHOTnull
at io.quarkus.bootstrap.BootstrapAppModelFactory.resolveAppModel(BootstrapAppModelFactory.java:297)
at io.quarkus.bootstrap.app.QuarkusBootstrap.bootstrap(QuarkusBootstrap.java:133)
at io.quarkus.test.junit.AbstractJvmQuarkusTestExtension.createAugmentor(AbstractJvmQuarkusTestExtension.java:189)
at io.quarkus.test.junit.QuarkusTestExtension.doJavaStart(QuarkusTestExtension.java:219)
at io.quarkus.test.junit.QuarkusTestExtension.ensureStarted(QuarkusTestExtension.java:610)
at io.quarkus.test.junit.QuarkusTestExtension.beforeAll(QuarkusTestExtension.java:660)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
... 37 more
Caused by: io.quarkus.bootstrap.resolver.maven.BootstrapMavenException: Failed to resolve dependencies for io.jenkins.plugins:horreum:hpi:0.1.5-SNAPSHOT
at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver.resolveRuntimeDeps(ApplicationDependencyTreeResolver.java:394)
at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver.resolve(ApplicationDependencyTreeResolver.java:145)
at io.quarkus.bootstrap.resolver.BootstrapAppModelResolver.buildAppModel(BootstrapAppModelResolver.java:337)
at io.quarkus.bootstrap.resolver.BootstrapAppModelResolver.doResolveModel(BootstrapAppModelResolver.java:288)
at io.quarkus.bootstrap.resolver.BootstrapAppModelResolver.resolveManagedModel(BootstrapAppModelResolver.java:168)
at io.quarkus.bootstrap.BootstrapAppModelFactory.resolveAppModel(BootstrapAppModelFactory.java:283)
... 48 more
Caused by: org.eclipse.aether.resolution.DependencyResolutionException: The following artifacts could not be resolved: org.jenkins-ci.main:jenkins-war:executable-war:2.440.3 (absent): Could not find artifact org.jenkins-ci.main:jenkins-war:executable-war:2.440.3 in repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:365)
at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver.resolveRuntimeDeps(ApplicationDependencyTreeResolver.java:389)
... 53 more
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: The following artifacts could not be resolved: org.jenkins-ci.main:jenkins-war:executable-war:2.440.3 (absent): Could not find artifact org.jenkins-ci.main:jenkins-war:executable-war:2.440.3 in repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:473)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:353)
... 54 more
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jenkins-ci.main:jenkins-war:executable-war:2.440.3 in repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/)
at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:42)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:537)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:449)
... 56 more

[

Anything else?

This project uses Quarkus Test framework 3.10.2 rather than relying on the Junit5 annotations directly.
The 2.30 commit introduced changes that define the type as executable-war. Which now cannot be resolved.
Switching to use executable-war type would suggest there is a plugin used in jenkins-war that generates the artifact. Building the module locally didn't produce for me an artifact with the name jenkins-war-2.440.3.executable-war.

Are you interested in contributing a fix?

I am happy to create a PR that switches the type back to war. With that changed back the project I am developing progresses beyond the error found in Actual Results.
ie

        <groupId>org.jenkins-ci.main</groupId>
        <artifactId>jenkins-war</artifactId>
        <version>${jenkins.version}</version>
        <type>war</type>
        <scope>test</scope>
        <exclusions>
          <exclusion>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
          </exclusion>
        </exclusions>
      </dependency>