The MTA CLI has traditionally been used for the following use cases:

• Quick analysis of applications in a local environment to cover situations like:
• Presales engagements that have no access to the customer infrastructure.
• Initial stages of customer engagements in which the OpenShift infrastructure hasn’t been provisioned yet.
• Traditional environments with no OpenShift infrastructure available at all, found in customers that are mostly interested in EAP or OpenJDK upgrades.

• Integration of analysis in CI/CD and other automation platforms:
• Quality gates based in analysis results for CI/CD (Bank of America)
• Analysis execution and publishing of custom reports (Inditex)

• Automated transformation of source code in the Java EE to Jakarta EE migration path:
• Must-have for supporting the launch of EAP 8.
• Required by customers like Garanti BBVA or Bank of America for large EAP upgrades.

• Test environment for custom rules authoring
• Simplify rules testing in a local environment by avoiding the requirement for an OpenShift cluster to test rules.

 

Users and Red Hat customers are used to having these features available in a single and easy to use CLI, so MTA 7 should provide a similar user experience to avoid disruption as much as possible.

 

 

User Stories

 

As a user I want to be able to list and use migration paths that come packaged with the tool without the need of providing any path to migration rules that back those default migration paths. Packaged migration paths should include those present in the MTA 6 CLI.

As a user I want to be able to list the sources and targets derived from the packaged migration paths.

As a user I want to be able to use custom rules in both the new YAML format or the legacy XML format. The usage of XML rules should be transparent and shouldn’t require any additional steps.

As a user I want to be able to input application source code and binaries by providing a path to the target assets. It should be possible to analyze an application and its binary dependencies at once by pointing to a source code directory and a dependencies directory.

As a user I want to be able to get the output for the analysis in YAML and JSON formats and specify the target path. 

 

Static reports

As a user I want to be able to generate static reports with the analysis results and have them placed in a given target path. These reports should include information about the issues, dependencies and technologies that were identified during the analysis, and support multiple applications.

 

Automated source code transformation 

As a user I want to be able to execute automated code transformation against application source code and migration rules.

 

Packaged transformation paths 

As a user I want to be able to execute automated code transformation against application source code and migration rules. Packaged migration paths should include Java EE to Jakarta EE, Spring Boot to Quarkus and XML migration rules to YAML migration rules.

Transformation input 

As a user I want to be able to input application source code or XML rules by providing a path to the target assets.

Transformation output 

As a user I want to be able to get transformed source code or YAML rules and specify the target path for the transformed assets.

Implementation

The following diagram depicts a potential architecture and analysis/transformation flow for the MTA CLI:

Diagram source can be found here.

The MTA CLI will leverage other binaries to execute the analyze and transform commands. Depending on the desired target, the CLI should be able to determine how to chain calls across multiple binaries.

Transformation will be achieved by using multiple providers. Transformation paths will include information about the required provider for their execution. Providers should be transparent to the end user, that should only care about the available paths in the system. One thing to discuss if we finally release the CLI upstream could be whether the user should be able to configure other paths and providers, but this should be locked downstream.

Commands and parameters

 

This is a basic list of commands and parameters for the MTA CLI. We need to decide which parameters from the Analyzer CLI and other CLIs we need to surface at the top level of the MTA CLI to allow the user to access a sufficient set of capabilities and configuration options.

 

Application analysis

 

Analysis will be executed via the analyze command. Flags/options for that command could include the following:

• --listTargets: Provides a list of the available migration targets available in the rules that come packaged with the MTA CLI.
• --listSources: Provides a list of the available migration sources available in the rules that come packaged with the MTA CLI.
• --input: Path to a directory with application source code or binaries.
• --output: Path to the directory where the analysis results will be stored.
• --dependenciesPath: Path to a directory that contains the application dependencies to override the default resolution mechanism.
• --target: Migration target for the rules to apply for the analysis. Multiple targets can be configured for an analysis.
• --source: Migration source for the rules to apply for the analysis. Multiple sources can be configured for an analysis.
• --skipReports: Skip static report generation.
• --JSONoutput: Generate JSON output instead of YAML.
• --analyzeThirdPartyDeps: By default, the CLI skips known Third Party libraries and only analyzes the application and its First Party dependencies. This flag forces the analysis of the application and all of its dependencies.
• --overwrite: Force overwrite of the output directory, without prompting.

A discussion needs to happen around the behavior of the CLI when a path that contains both binaries and source is passed as input. The Windup CLI has a certain behavior for that, but it should be decided if we want to continue with that or define something different that better suits the new analyzer.

Command samples

 

Analysis of an application source code:

mta analyze --input /home/user/myapp --output /home/user/reports --target eap7 --target cloud-readiness --source websphere 

Analysis of an application source code + dependencies:

mta analyze --input /home/user/myapp --dependencies /home/user/dependencies --output /home/user/reports --target eap7 --target cloud-readiness --source websphere

Analysis of multiple binaries in a directory:

mta analyze --input /home/user/myappsdir --output /home/user/reports --target eap7 --target cloud-readiness --source websphere 

 

Application Transformation

Automated code transformation will be executed via the transform command. This command will require a subcommand to specify the type of transformation that the user might need in a given moment:

• openrewrite: Execute an OpenRewrite recipe against a certain codebase.
• rules: Transform legacy XML rules into the new YAML syntax.

Flags/options for that both subcommands could include the following:

• --listTargets: Provides a list of the available transformation targets packaged with the MTA CLI.
• --input: Path to a directory with application source code or XML rules.
• --output: Path to the directory where the transformed assets will be stored.
• --target: Transformation target for the application.

Command Samples

 

Transform the XML files of a Java EE application to Jakarta EE:

mta transform openrewrite --input /home/user/myapp --output /home/user/mytransformedapp --target jakartaEEXML

 

Transform legacy XML rules to YAML rules:

mta transform rules --input /home/user/rulesdir --output /home/user/transformedrules --target YAMLRules