Full name:
org.jenkins-ci.tools:maven-hpi-plugin:3.7:hpi
Description:
Attributes:
| Name | Type | Since | Description |
|---|---|---|---|
| minimumJavaVersion | String | 3.0 | Specify the minimum version of Java that this plugin requires. |
| Name | Type | Since | Description |
|---|---|---|---|
| archive | MavenArchiveConfiguration | 3.0 | The maven archive configuration to use. |
| classesDirectory | File | 3.0 | The directory containing generated classes. Default value is: ${project.build.outputDirectory}. |
| compatibleSinceVersion | String | 3.0 | Optional - the oldest version of this plugin which the current
version is configuration-compatible with. User property is: hpi.compatibleSinceVersion. |
| containerConfigXML | File | 3.0 | The path to the context.xml file to use. Default value is: ${maven.war.containerConfigXML}. |
| dependentWarExcludes | String | 3.0 | The comma separated list of tokens to exclude when doing a way
overlay. |
| dependentWarIncludes | String | 3.0 | The comma separated list of tokens to include when doing a war
overlay. Default value is: **. |
| failOnVersionOverrideToDifferentRelease | boolean | 2.4 | Controls the safety check that prevents a
snapshotPluginVersionOverride from switching to a
different release version. Default value is: true. |
| filters | List | 3.0 | (no description) Default value is: ${project.build.filters}. |
| globalMaskClasses | String | 1.92 | Like the maskClasses parameter, but it applies at the
boundary between core and all the plugins.
This mechanism is intended for those plugins that bring JavaEE APIs (such as the database plugin, which brings in the JPA API.) Other plugins that depend on the database plugin can still see the JPA API through the container classloader, so to make them all resolve to the JPA API in the database plugin, the database plugin needs to rely on this mechanism. |
| hpiName | String | 3.0 | The name of the generated hpi. Default value is: ${project.build.finalName}. |
| jarClassifier | String | 1.115 | The classifier to use when searching for the jar artifact. |
| jenkinsCoreId | String | 1.65 | Optional string that represents "groupId:artifactId" of Jenkins
core jar. If left unspecified, the default groupId/artifactId pair
for Jenkins is looked for. |
| jenkinsCoreVersionOverride | String | 3.0 | Optional string that represents the version of Jenkins core to
report plugins as requiring. This parameter is only used when
unbundling functionality from Jenkins core and the version
specified will be ignored if older than the autodetected version. |
| maskClasses | String | 3.0 | [ws|tab|CR|LF]+ separated list of package prefixes that your plugin
doesn't want to see from the core.
Tokens in this list is prefix-matched against the fully-qualified class name, so add "." to the end of each package name, like "com.foo. com.bar." |
| outputDirectory | String | 3.0 | The directory for the generated WAR. Default value is: ${project.build.directory}. |
| pluginFirstClassLoader | boolean | 1.53 | Change the classloader preference such that classes locally bundled
in this plugin will take precedence over those that are defined by
the dependency plugins.
This is useful if the plugins that you want to depend on exposes conflicting versions of the libraries you are using, but enabling this switch makes your code susceptible to classloader constraint violations. |
| pluginVersionDescription | String | 3.0 | Additional information that accompanies the version number of the
plugin. Useful to distinguish snapshot builds. For example, if you
are building snapshot plugins from Jenkins, you can put the build
number in here by running Maven with
"-Dplugin.version.description=$BUILD_TAG" Default value is: ${plugin.version.description}. |
| sandboxStatus | String | 3.0 | Optional - sandbox status of this plugin. |
| snapshotPluginVersionOverride | String | 2.4 | Optional - the version to use in place of the project version in
the event that the project version is a -SNAPSHOT. If specified,
the value must start with the project version
after removing the terminal -SNAPSHOT, for example if
the project version is 1.2.3-SNAPSHOT then the
snapshotPluginVersionOverride could be
1.2.3-rc45.cafebabe-SNAPSHOT or
1.2.3-20180430.123233-56, etc, but it could not be
1.2.4 as that does not start with the project version.
When testing plugin builds on a locally hosted update centre, in
order to be allowed to update the plugin, the update centre must
report the plugin version as greater than the currently installed
plugin version. If you are using a Continuous Delivery model for
your plugin (i.e. where the master branch stays on a version like
1.x-SNAPSHOT and releases are tagged but not merged
back to master (in order to prevent merge conflicts) then you will
find that you cannot update the plugin when building locally as
1.x-SNAPSHOT is never less than
1.x-SNAPSHOT. Thus in order to test plugin upgrade (in
say an acceptance test), you need to override the plugin version
for non-releases. Typically you would use something like git-timestamp-maven-plugin
to populate a property with the version and then use this
configuration to provide the version. |
| warSourceDirectory | File | 3.0 | Single directory for extra files to include in the WAR. Default value is: ${basedir}/src/main/webapp. |
| warSourceExcludes | String | 3.0 | The comma separated list of tokens to exclude from the WAR. Alias is: excludes. |
| warSourceIncludes | String | 3.0 | The comma separated list of tokens to include in the WAR. Default value is: **. Alias is: includes. |
| webResources | Resource[] | 3.0 | The list of webResources we want to transfer. |
| webappDirectory | File | 3.0 | The directory where the webapp is built. Default value is: ${project.build.directory}/${project.build.finalName}. |
| workDirectory | File | 3.0 | Directory to unpack dependent WARs into if needed Default value is: ${project.build.directory}/war/work. |
failOnVersionOverrideToDifferentRelease:
This mechanism is intended for those plugins that bring JavaEE APIs (such as the database plugin, which brings in the JPA API.) Other plugins that depend on the database plugin can still see the JPA API through the container classloader, so to make them all resolve to the JPA API in the database plugin, the database plugin needs to rely on this mechanism.
Tokens in this list is prefix-matched against the fully-qualified class name, so add "." to the end of each package name, like "com.foo. com.bar."
This is useful if the plugins that you want to depend on exposes conflicting versions of the libraries you are using, but enabling this switch makes your code susceptible to classloader constraint violations.
snapshotPluginVersionOverride: