Skip to content

Add apply-ifix goal for WebSphere Liberty iFix application - #2069

Open
takakiyo wants to merge 5 commits into
OpenLiberty:mainfrom
takakiyo:feature/apply-ifix
Open

Add apply-ifix goal for WebSphere Liberty iFix application#2069
takakiyo wants to merge 5 commits into
OpenLiberty:mainfrom
takakiyo:feature/apply-ifix

Conversation

@takakiyo

Copy link
Copy Markdown

Summary

This pull request adds a new Maven goal apply-ifix to the Liberty Maven Plugin that
automates the application of IBM WebSphere Liberty iFix JAR files to the Liberty runtime
installation during the build lifecycle.

Motivation

WebSphere Liberty iFix JARs (e.g. 250012-wlp-archive-IFPH69485.jar) are security and
bug-fix patches distributed by IBM. Previously, users had to apply them manually by running
java -jar <ifix>.jar --installLocation <wlp-dir> outside the Maven build. This change
integrates that step into the standard Liberty Maven Plugin lifecycle so that iFix application
becomes a reproducible, automated part of the build.

Changes

New file: liberty-maven-plugin/.../server/ApplyIfixMojo.java

Implements the apply-ifix goal as a subclass of PluginConfigSupport.

Key behaviour:

  • Disabled by default (applyLibertyiFix=false). No work is done unless the user explicitly opts in.
  • WebSphere Liberty only. The runtimeArtifact groupId must be com.ibm.websphere.appserver.runtime. Open Liberty and pre-installed (installDirectory) configurations are not supported; both cases are handled according to stopOniFixApplyError.
  • Version validation. Before applying each JAR, the productVersion field from the Applies-To attribute in META-INF/MANIFEST.MF is compared against the installed Liberty version read from lib/versions/*.properties (com.ibm.websphere.productVersion). A mismatch is treated as an error.
  • Applies iFix JARs found in libertyifixDir (default: ${project.basedir}/src/main/liberty/ifixes) by invoking java -jar <ifix>.jar --installLocation <installDirectory> via the Ant Java task, consistent with the existing installLicense() pattern in BasicSupport.
  • Error handling is centralised through stopOniFixApplyError (default true): trueMojoExecutionException (build fails); false → WARNING (build continues).

New @Parameter annotations:

Parameter Default Description
applyLibertyiFix false Enable iFix application
libertyifixDir ${project.basedir}/src/main/liberty/ifixes Directory containing iFix JARs
stopOniFixApplyError true Fail build on any iFix error

Modified: StartDebugMojoSupport.java

Added runLibertyMojoApplyIfix() helper method following the same pattern as the existing runLibertyMojoInstallFeature() and runLibertyMojoDeploy() helpers.

Modified: DevMojo.java

runLibertyMojoApplyIfix() is called immediately after runLibertyMojoInstallFeature() in two places:

  1. Server startup path — when features are installed before the server first starts
  2. pom.xml change-detection path — when the installFeature flag is raised during a live reload cycle

The call is unconditional; ApplyIfixMojo.execute() exits immediately when applyLibertyiFix=false (the default), so there is no overhead for users who do not enable the feature.

Modified: ExecuteMojoUtil.java

Added APPLY_IFIX_PARAMS list and a liberty-maven-plugin:apply-ifix case in validateConfiguration(). Without this, the mojo-executor path used by dev mode passed the raw <runtimeArtifact> alias element through to ApplyIfixMojo, causing Maven to fail with "Cannot find 'runtimeArtifact' in class ApplyIfixMojo" (the field is named assemblyArtifact; runtimeArtifact is only a @Parameter alias). The new case calls convertLibertyAlias() and stripConfigElements() consistently with the other Liberty goals.

Modified: META-INF/plexus/components.xml

Added liberty:apply-ifix to the prepare-package phase of the liberty-assembly lifecycle, after liberty:install-feature.

New file: docs/apply-ifix.md

User-facing reference documentation in the same format as existing goal docs. Covers all parameters, the iFix JAR naming convention, version validation behaviour, and three usage examples.

Modified: README.md

  • Added apply-ifix to the goals table (alphabetical order).
  • Updated the liberty-assembly lifecycle phase table to include liberty:apply-ifix in the prepare-package row.

Testing

Verified with a liberty-assembly project using com.ibm.websphere.appserver.runtime:wlp-kernel:25.0.0.12 and two test iFix JARs (250012-wlp-archive-IFPH69485.jar, 250012-wlp-archive-IFPH70327.jar):

  • ./mvnw clean install passes with both iFix JARs applied successfully during prepare-package.
  • The Liberty server starts cleanly after iFix application.
  • Unit tests in ci.maven (./mvnw install) pass with 0 failures.

Example Configuration

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <configuration>
        <runtimeArtifact>
            <groupId>com.ibm.websphere.appserver.runtime</groupId>
            <artifactId>wlp-webProfile10</artifactId>
            <version>25.0.0.12</version>
            <type>zip</type>
        </runtimeArtifact>
        <applyLibertyiFix>true</applyLibertyiFix>
        <!-- libertyifixDir defaults to src/main/liberty/ifixes -->
    </configuration>
</plugin>

Place iFix JAR files under src/main/liberty/ifixes/. They will be applied automatically during prepare-package after features are installed.

takakiyo added 5 commits July 15, 2026 22:55
Adds a new Maven goal 'apply-ifix' that applies IBM WebSphere Liberty
iFix JAR files to the Liberty runtime installation.

Key features:
- Enabled only when <applyLibertyiFix>true</applyLibertyiFix> is set
- Reads iFix JARs from <libertyifixDir> (default:
  ${project.basedir}/src/main/liberty/ifixes)
- Validates the iFix target version against the installed Liberty version
  by reading the 'Applies-To' attribute in META-INF/MANIFEST.MF
- Only supports WebSphere Liberty (runtimeArtifact groupId must be
  com.ibm.websphere.appserver.runtime); direct installDirectory
  configuration is not supported
- <stopOniFixApplyError> (default: true) controls whether errors fail
  the build or are reported as warnings
- Registered in the liberty-assembly lifecycle prepare-package phase
  after install-feature

Signed-off-by: IBM Developer
In dev mode (liberty:dev), call runLibertyMojoApplyIfix() immediately
after runLibertyMojoInstallFeature() in two places:

1. Server startup path: when features are installed before the server
   is first started (!container && (!skipInstallFeature || isNewInstallation))
2. pom.xml change-detection path: when installFeature flag is set
   during a live reload cycle

The call is always issued; ApplyIfixMojo.execute() exits immediately
when applyLibertyiFix=false (the default), so there is no overhead
unless the feature is explicitly enabled.
When dev goal invokes apply-ifix via mojo-executor, getPluginGoalConfig()
passes the merged plugin <configuration> to validateConfiguration(). Without
a case for 'liberty-maven-plugin:apply-ifix' the switch fell through to
default, leaving the raw <runtimeArtifact> alias element in the config DOM.
Maven then fails with 'Cannot find runtimeArtifact in ApplyIfixMojo' because
the field is named assemblyArtifact (runtimeArtifact is only an @parameter
alias).

Fix: add APPLY_IFIX_PARAMS list and a dedicated switch case that calls
convertLibertyAlias() (to rename runtimeArtifact -> assemblyArtifact) and
stripConfigElements() to retain only the parameters relevant to apply-ifix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant