Over the years, we have heard from users of the WebSphere Application Migration Toolkit for Application Binaries (aka binary scanner) that they have added the binary scanner to their build pipeline. This allows their application to be evaluated using the binary scanner with each build of the application (or a subset of builds) to ensure that they are monitoring their application as they prepare for an upcoming application server migration or Java SE migration. For more information on the binary scanner itself, check out my blog What is the Migration Toolkit for Application Binaries?.
To make this process easier we have released the binary scanner to the Maven Central Repository. This means you can more easily download the latest binary scanner as part of your build, and then run it against your application as part of the build process.
I will walk through how you can set up the binary scanner as part of a Maven build, but a similar technique can be used regardless of the build tooling you use, be it Gradle, Ant, or something else. For this example I started with the Creating a RESTful web service guide. If you want to, you can clone the fork of the repo with my modifications from my Github. I modified the Java classes in the project from the original guide slightly to include some more interesting analysis results.
For the Maven execution, we will use the Maven Exec Java Plugin. To do that, I added the following snippet to my pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<includePluginDependencies>true</includePluginDependencies>
<mainClass>com.ibm.ws.report.binary.cmdline.DriveScan</mainClass>
<addOutputToClasspath>false</addOutputToClasspath>
<arguments>
<argument>${project.build.directory}/${project.build.finalName}.${project.packaging}</argument>
<argument>--analyze</argument>
<argument>--targetJava=java17</argument>
<argument>--nobrowser</argument>
<argument>--output=${project.build.directory}</argument>
</arguments>
</configuration>
<dependencies>
<dependency>
<groupId>com.ibm.websphere.appmod.tools</groupId>
<artifactId>binary-app-scanner</artifactId>
<version>22.0.0.1</version>
<type>jar</type>
</dependency>
</dependencies>
</plugin>
Looking at the configuration in the pom.xml, we specify the main class of the binary scanner and add the appropriate arguments. In this case the path to our built application archive, along with the analyze option, as well as the targetJava version. If desired, other options such as targetAppServer, targetJavaEE, or sourceJava could also be used. The nobrowser option is specified so the report isn't opened in a web browser when finished. By default, the report will be created in the current working directory. This probably isn't what you want. In the example I use the output parameter to set the output location as the finish/target directory. In the dependencies section we add the coordinates for the binary scanner in Maven Central. Currently the latest release is 22.0.0.1, but be sure to check if there is a new release by the time you are reading this!
The binary scanner can then be run with the command: mvn exec:java. You can add binary scanning to a standard build command like mvn clean install by updating it to be mvn clean install exec:java. This will result in the binary scanner report being produced in the directory specified using the output parameter. You can move the report elsewhere for storage or viewing, following your standard build conventions. For my application, the report produced three results related to a migration to Java 17:
For more details on the analysis report and the supported options, check out my blog Getting Down to the Details of Application Migration.
The binary scanner is a useful tool for evaluating your application for a variety of modernization scenarios, including WebSphere traditional to Liberty and Java SE migrations. Further, the binary scanner allows for you to write your own migration rules, meaning you can customize the scanner to your exact needs - for more details on writing user-defined rules check out the User-defined Rules in the Migration Toolkit for Application Binaries blog. To ensure you have the latest reports on your application and to monitor for application changes that will cause migration issues, try adding the binary scanner directly to your build pipeline!