Appendix A. Reference material


A.1. About MTR command-line arguments

The following is a detailed description of the available MTR command line arguments.

Note

To run the MTR command without prompting, for example when executing from a script, you must use the following arguments:

  • --batchMode
  • --overwrite
  • --input
  • --target
Table A.1. MTR CLI arguments
ArgumentDescription

--additionalClassPath

A space-delimited list of additional JAR files or directories to add to the class path so that they are available for decompilation or other analysis.

--addonDir

Add the specified directory as a custom add-on repository.

--analyzeKnownLibraries

Flag to analyze known software artifacts embedded within your application. By default, MTR only analyzes application code.

Note

This option may result in a longer execution time and a large number of migration issues being reported.

--batchMode

Flag to specify that MTR should be run in a non-interactive mode without prompting for confirmation. This mode takes the default values for any parameters not passed in to the command line.

--debug

Flag to run MTR in debug mode.

--disableTattletale

Flag to disable generation of the Tattletale report. If both enableTattletale and disableTattletale are set to true, then disableTattletale will be ignored and the Tattletale report will still be generated.

--discoverPackages

Flag to list all available packages in the input binary application.

--enableClassNotFoundAnalysis

Flag to enable analysis of Java files that are not available on the class path. This should not be used if some classes will be unavailable at analysis time.

--enableCompatibleFilesReport

Flag to enable generation of the Compatible Files report. Due to processing all files without found issues, this report may take a long time for large applications.

--enableTattletale

Flag to enable generation of a Tattletale report for each application. This option is enabled by default when eap is in the included target. If both enableTattletale and disableTattletale are set to true, then disableTattletale will be ignored and the Tattletale report will still be generated.

--enableTransactionAnalysis

[Technology Preview] Flag to enable generation of a Transactions report that displays the call stack, which executes operations on relational database tables. The Enable Transaction Analysis feature supports Spring Data JPA and the traditional preparedStatement() method for SQL statement execution. It does not support ORM frameworks, such as Hibernate.

Note

enableTransactionAnalysis is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

--excludePackages

A space-delimited list of packages to exclude from evaluation. For example, entering com.mycompany.commonutilities excludes all classes whose package names begin with com.mycompany.commonutilities.

--excludeTags

A space-delimited list of tags to exclude. When specified, rules with these tags will not be processed. To see the full list of tags, use the --listTags argument.

--explodedApp

Flag to indicate that the provided input directory contains source files for a single application.

--exportCSV

Flag to export the report data to a CSV file on your local file system. MTR creates the file in the directory specified by the --output argument. The CSV file can be imported into a spreadsheet program for data manipulation and analysis.

--exportSummary

Flag to instruct MTR to generate an analysisSummary.json export file in the output directory. The file contains analysis summary information for each application analyzed, including the number of incidents and story points by category, and all of the technology tags associated with the analyzed applications.

--exportZipReport

This argument creates a reports.zip file in the output folder. The file contains the analysis output, typically, the reports. If requested, it can also contain the CSV export files.

--help

Display the MTR help message.

--immutableAddonDir

Add the specified directory as a custom read-only add-on repository.

--includeTags

A space-delimited list of tags to use. When specified, only rules with these tags will be processed. To see the full list of tags, use the --listTags argument.

--input

A space-delimited list of the path to the file or directory containing one or more applications to be analyzed. This argument is required.

--install

Specify add-ons to install. The syntax is <GROUP_ID>:<ARTIFACT_ID>[:<VERSION>]. For example, --install core-addon-x or --install org.example.addon:example:1.0.0.

--keepWorkDirs

Flag to instruct MTR to not delete temporary working files, such as the graph database and extracted archive files. This is useful for debugging purposes.

--legacyReports

Flag to instruct MTR to generate the old format reports instead of the new format reports.

--list

Flag to list installed add-ons.

--listSourceTechnologies

Flag to list all available source technologies.

--listTags

Flag to list all available tags.

--listTargetTechnologies

Flag to list all available target technologies.

--mavenize

Flag to create a Maven project directory structure based on the structure and content of the application. This creates pom.xml files using the appropriate Java EE API and the correct dependencies between project modules. See also the --mavenizeGroupId option.

--mavenizeGroupId

When used with the --mavenize option, all generated pom.xml files will use the provided value for their <groupId>. If this argument is omitted, MTR will attempt to determine an appropriate <groupId> based on the application, or will default to com.mycompany.mavenized.

--online

Flag to allow network access for features that require it. Currently only validating XML schemas against external resources relies on Internet access. Note that this comes with a performance penalty.

--output

Specify the path to the directory to output the report information generated by MTR.

--overwrite

Flag to force delete the existing output directory specified by --output. If you do not specify this argument and the --output directory exists, you are prompted to choose whether to overwrite the contents.

Important

Do not overwrite a report output directory that contains important information.

--packages

A space-delimited list of the packages to be evaluated by MTR. It is highly recommended to use this argument.

--remove

Remove the specified add-ons. The syntax is <GROUP_ID>:<ARTIFACT_ID>[:<VERSION>]. For example, --remove core-addon-x or --remove org.example.addon:example:1.0.0.

--skipReports

Flag to indicate that HTML reports should not be generated. A common use of this argument is when exporting report data to a CSV file using --exportCSV.

--source

A space-delimited list of one or more source technologies, servers, platforms, or frameworks to migrate from. This argument, in conjunction with the --target argument, helps to determine which rulesets are used. Use the --listSourceTechnologies argument to list all available sources.

--sourceMode

Flag to indicate that the application to be evaluated contains source files rather than compiled binaries. The sourceMode argument has been deprecated. There is no longer the need to specify it. MTR can intuitively process any inputs that are presented to it. In addition, project source folders can be analyzed with binary inputs within the same analysis execution.

--target

A space-delimited list of one or more target technologies, servers, platforms, or frameworks to migrate to. This argument, in conjunction with the --source argument, helps to determine which rulesets are used. Use the --listTargetTechnologies argument to list all available targets.

--userIgnorePath

Specify a location, in addition to ${user.home}/.mtr/ignore/, for MTR to identify files that should be ignored.

--userLabelsDirectory

Specify a location for MTR to look for custom Target Runtime Labels. The value can be a directory containing label files or a single label file. The Target Runtime Label files must use the .windup.label.xml suffix. The shipped Target Runtime Labels are defined within $MTR_HOME/rules/migration-core/core.windup.label.xml.

--userRulesDirectory

Specify a location, in addition to <MTR_HOME>/rules/ and ${user.home}/.mtr/rules/, for MTR to look for custom MTR rules. The value can be a directory containing ruleset files or a single ruleset file. The ruleset files must use the .windup.xml suffix.

--version

Display the MTR version.

--skipSourceCodeReports

This option skips generating a Source code report when generating the application analysis report. Use this advanced option when concerned about source code information appearing in the application analysis.

A.1.1. Specifying the input

A space-delimited list of the path to the file or directory containing one or more applications to be analyzed. This argument is required.

Usage

--input <INPUT_ARCHIVE_OR_DIRECTORY> [...]

Depending on whether the input file type provided to the --input argument is a file or directory, it will be evaluated as follows depending on the additional arguments provided.

Directory
--explodedApp--sourceModeNeither Argument

The directory is evaluated as a single application.

The directory is evaluated as a single application.

Each subdirectory is evaluated as an application.

File
--explodedApp--sourceModeNeither Argument

Argument is ignored; the file is evaluated as a single application.

The file is evaluated as a compressed project.

The file is evaluated as a single application.

A.1.2. Specifying the output directory

Specify the path to the directory to output the report information generated by MTR.

Usage

--output <OUTPUT_REPORT_DIRECTORY>

  • If omitted, the report will be generated in an <INPUT_ARCHIVE_OR_DIRECTORY>.report directory.
  • If the output directory exists, you will be prompted with the following (with a default of N).

    Overwrite all contents of "/home/username/<OUTPUT_REPORT_DIRECTORY>" (anything already in the directory will be deleted)? [y,N]

However, if you specify the --overwrite argument, MTR will proceed to delete and recreate the directory. See the description of this argument for more information.

A.1.3. Setting the source technology

A space-delimited list of one or more source technologies, servers, platforms, or frameworks to migrate from. This argument, in conjunction with the --target argument, helps to determine which rulesets are used. Use the --listSourceTechnologies argument to list all available sources.

Usage

--source <SOURCE_1> <SOURCE_2>

The --source argument now provides version support, which follows the Maven version range syntax. This instructs MTR to only run the rulesets matching the specified versions. For example, --source eap:5.

Warning

When migrating to JBoss EAP, be sure to specify the version, for example, eap:6. Specifying only eap will run rulesets for all versions of JBoss EAP, including those not relevant to your migration path.

See Supported migration paths in Introduction to the Migration Toolkit for Runtimes for the appropriate JBoss EAP version.

A.1.4. Setting the target technology

A space-delimited list of one or more target technologies, servers, platforms, or frameworks to migrate to. This argument, in conjunction with the --source argument, helps to determine which rulesets are used. If you do not specify this option, you are prompted to select a target. Use the --listTargetTechnologies argument to list all available targets.

Usage

--target <TARGET_1> <TARGET_2>

The --target argument now provides version support, which follows the Maven version range syntax. This instructs MTR to only run the rulesets matching the specified versions. For example, --target eap:7.

Warning

When migrating to JBoss EAP, be sure to specify the version in the target, for example, eap:6. Specifying only eap will run rulesets for all versions of JBoss EAP, including those not relevant to your migration path.

See Supported migration paths in Introduction to the Migration Toolkit for Runtimes for the appropriate JBoss EAP version.

A.1.5. Selecting packages

A space-delimited list of the packages to be evaluated by MTR. It is highly recommended to use this argument.

Usage

--packages <PACKAGE_1> <PACKAGE_2> <PACKAGE_N>

  • In most cases, you are interested only in evaluating custom application class packages and not standard Java EE or third party packages. The <PACKAGE_N> argument is a package prefix; all subpackages will be scanned. For example, to scan the packages com.mycustomapp and com.myotherapp, use --packages com.mycustomapp com.myotherapp argument on the command line.
  • While you can provide package names for standard Java EE third party software like org.apache, it is usually best not to include them as they should not impact the migration effort.
Warning

If you omit the --packages argument, every package in the application is scanned, which can impact performance.

A.2. Supported technology tags

The following technology tags are supported in MTR 1.2.7:

  • 0MQ Client
  • 3scale
  • Acegi Security
  • AcrIS Security
  • ActiveMQ library
  • Airframe
  • Airlift Log Manager
  • AKKA JTA
  • Akka Testkit
  • Amazon SQS Client
  • AMQP Client
  • Anakia
  • AngularFaces
  • ANTLR StringTemplate
  • AOP Alliance
  • Apache Accumulo Client
  • Apache Aries
  • Apache Commons JCS
  • Apache Commons Validator
  • Apache Flume
  • Apache Geronimo
  • Apache Hadoop
  • Apache HBase Client
  • Apache Ignite
  • Apache Karaf
  • Apache Mahout
  • Apache Meecrowave JTA
  • Apache Sirona JTA
  • Apache Synapse
  • Apache Tapestry
  • Apiman
  • Applet
  • Arquillian
  • AspectJ
  • Atomikos JTA
  • Avalon Logkit
  • Axion Driver
  • Axis
  • Axis2
  • BabbageFaces
  • Bean Validation
  • BeanInject
  • Blaze
  • Blitz4j
  • BootsFaces
  • Bouncy Castle
  • ButterFaces
  • Cache API
  • Cactus
  • Camel
  • Camel Messaging Client
  • Camunda
  • Cassandra Client
  • CDI
  • Cfg Engine
  • Chunk Templates
  • Cloudera
  • Coherence
  • Common Annotations
  • Composite Logging
  • Composite Logging JCL
  • Concordion
  • CSS
  • Cucumber
  • Dagger
  • DbUnit
  • Demoiselle JTA
  • Derby Driver
  • Drools
  • DVSL
  • Dynacache
  • EAR Deployment
  • Easy Rules
  • EasyMock
  • Eclipse RCP
  • EclipseLink
  • Ehcache
  • EJB
  • EJB XML
  • Elasticsearch
  • Entity Bean
  • EtlUnit
  • Eureka
  • Everit JTA
  • Evo JTA
  • Feign
  • File system Logging
  • FormLayoutMaker
  • FreeMarker
  • Geronimo JTA
  • GFC Logging
  • GIN
  • GlassFish JTA
  • Google Guice
  • Grails
  • Grapht DI
  • Guava Testing
  • GWT
  • H2 Driver
  • Hamcrest
  • Handlebars
  • HavaRunner
  • Hazelcast
  • Hdiv
  • Hibernate
  • Hibernate Cfg
  • Hibernate Mapping
  • Hibernate OGM
  • HighFaces
  • HornetQ Client
  • HSQLDB Driver
  • HTTP Client
  • HttpUnit
  • ICEfaces
  • Ickenham
  • Ignite JTA
  • Ikasan
  • iLog
  • Infinispan
  • Injekt for Kotlin
  • Iroh
  • Istio
  • Jamon
  • Jasypt
  • Java EE Batch
  • Java EE Batch API
  • Java EE JACC
  • Java EE JAXB
  • Java EE JAXR
  • Java EE JSON-P
  • Java Transaction API
  • JavaFX
  • JavaScript
  • Javax Inject
  • JAX-RS
  • JAX-WS
  • JayWire
  • JBehave
  • JBoss Cache
  • JBoss EJB XML
  • JBoss logging
  • JBoss Transactions
  • JBoss Web XML
  • JBossMQ Client
  • JBPM
  • JCA
  • Jcabi Log
  • JCache
  • JCunit
  • JDBC
  • JDBC datasources
  • JDBC XA datasources
  • Jersey
  • Jetbrick Template
  • Jetty
  • JFreeChart
  • JFunk
  • JGoodies
  • JMock
  • JMockit
  • JMS Connection Factory
  • JMS Queue
  • JMS Topic
  • JMustache
  • JNA
  • JNI
  • JNLP
  • JPA entities
  • JPA Matchers
  • JPA named queries
  • JPA XML
  • JSecurity
  • JSF
  • JSF Page
  • JSilver
  • JSON-B
  • JSP Page
  • JSTL
  • JTA
  • Jukito
  • JUnit
  • Ka DI
  • Keyczar
  • Kibana
  • KLogger
  • Kodein
  • Kotlin Logging
  • KouInject
  • KumuluzEE JTA
  • LevelDB Client
  • Liferay
  • LiferayFaces
  • Lift JTA
  • Log.io
  • Log4J
  • Log4s
  • Logback
  • Logging Utils
  • Logstash
  • Lumberjack
  • Macros
  • Magicgrouplayout
  • Mail
  • Management EJB
  • MapR
  • MckoiSQLDB Driver
  • Memcached
  • Message (MDB)
  • Micro DI
  • Micrometer
  • Microsoft SQL Driver
  • MiGLayout
  • MinLog
  • Mixer
  • Mockito
  • MongoDB Client
  • Monolog
  • Morphia
  • MRules
  • Mule
  • Mule Functional Test Framework
  • MultithreadedTC
  • Mycontainer JTA
  • MyFaces
  • MySQL Driver
  • Narayana Arjuna
  • Needle
  • Neo4j
  • NLOG4J
  • Nuxeo JTA/JCA
  • OACC
  • OAUTH
  • OCPsoft Logging Utils
  • OmniFaces
  • OpenFaces
  • OpenPojo
  • OpenSAML
  • OpenWS
  • OPS4J Pax Logging Service
  • Oracle ADF
  • Oracle DB Driver
  • Oracle Forms
  • Orion EJB XML
  • Orion Web XML
  • Oscache
  • OTR4J
  • OW2 JTA
  • OW2 Log Util
  • OWASP CSRF Guard
  • OWASP ESAPI
  • Peaberry
  • Pega
  • Persistence units
  • Petals EIP
  • PicketBox
  • PicketLink
  • PicoContainer
  • Play
  • Play Test
  • Plexus Container
  • Polyforms DI
  • Portlet
  • PostgreSQL Driver
  • PowerMock
  • PrimeFaces
  • Properties
  • Qpid Client
  • RabbitMQ Client
  • RandomizedTesting Runner
  • Resource Adapter
  • REST Assured
  • Restito
  • RichFaces
  • RMI
  • RocketMQ Client
  • Rythm Template Engine
  • SAML
  • Santuario
  • Scalate
  • Scaldi
  • Scribe
  • Seam
  • Security Realm
  • ServiceMix
  • Servlet
  • ShiftOne
  • Shiro
  • Silk DI
  • SLF4J
  • Snippetory Template Engine
  • SNMP4J
  • Socket handler logging
  • Spark
  • Specsy
  • Spock
  • Spring
  • Spring Batch
  • Spring Boot
  • Spring Boot Actuator
  • Spring Boot Cache
  • Spring Boot Flo
  • Spring Cloud Config
  • Spring Cloud Function
  • Spring Data
  • Spring Data JPA
  • spring DI
  • Spring Integration
  • Spring JMX
  • Spring Messaging Client
  • Spring MVC
  • Spring Properties
  • Spring Scheduled
  • Spring Security
  • Spring Shell
  • Spring Test
  • Spring Transactions
  • Spring Web
  • SQLite Driver
  • SSL
  • Standard Widget Toolkit (SWT)
  • Stateful (SFSB)
  • Stateless (SLSB)
  • Sticky Configured
  • Stripes
  • Struts
  • SubCut
  • Swagger
  • SwarmCache
  • Swing
  • SwitchYard
  • Syringe
  • Talend ESB
  • Teiid
  • TensorFlow
  • Test Interface
  • TestNG
  • Thymeleaf
  • TieFaces
  • tinylog
  • Tomcat
  • Tornado Inject
  • Trimou
  • Trunk JGuard
  • Twirl
  • Twitter Util Logging
  • UberFire
  • Unirest
  • Unitils
  • Vaadin
  • Velocity
  • Vlad
  • Water Template Engine
  • Web Services Metadata
  • Web Session
  • Web XML File
  • WebLogic Web XML
  • Webmacro
  • WebSocket
  • WebSphere EJB
  • WebSphere EJB Ext
  • WebSphere Web XML
  • WebSphere WS Binding
  • WebSphere WS Extension
  • Weka
  • Weld
  • WF Core JTA
  • Wicket
  • Winter
  • WSDL
  • WSO2
  • WSS4J
  • XACML
  • XFire
  • XMLUnit
  • Zbus Client
  • Zipkin

A.3. About rule story points

A.3.1. What are story points?

Story points are an abstract metric commonly used in Agile software development to estimate the level of effort needed to implement a feature or change.

The Migration Toolkit for Runtimes uses story points to express the level of effort needed to migrate particular application constructs, and the application as a whole. It does not necessarily translate to man-hours, but the value should be consistent across tasks.

A.3.2. How story points are estimated in rules

Estimating the level of effort for the story points for a rule can be tricky. The following are the general guidelines MTR uses when estimating the level of effort required for a rule.

Level of EffortStory PointsDescription

Information

0

An informational warning with very low or no priority for migration.

Trivial

1

The migration is a trivial change or a simple library swap with no or minimal API changes.

Complex

3

The changes required for the migration task are complex, but have a documented solution.

Redesign

5

The migration task requires a redesign or a complete library change, with significant API changes.

Rearchitecture

7

The migration requires a complete rearchitecture of the component or subsystem.

Unknown

13

The migration solution is not known and may need a complete rewrite.

A.3.3. Task category

In addition to the level of effort, you can categorize migration tasks to indicate the severity of the task. The following categories are used to group issues to help prioritize the migration effort.

Mandatory
The task must be completed for a successful migration. If the changes are not made, the resulting application will not build or run successfully. Examples include replacement of proprietary APIs that are not supported in the target platform.
Optional
If the migration task is not completed, the application should work, but the results may not be optimal. If the change is not made at the time of migration, it is recommended to put it on the schedule soon after your migration is completed.
Potential
The task should be examined during the migration process, but there is not enough detailed information to determine if the task is mandatory for the migration to succeed. An example of this would be migrating a third-party proprietary type where there is no directly compatible type.
Information
The task is included to inform you of the existence of certain files. These may need to be examined or modified as part of the modernization effort, but changes are typically not required.

For more information on categorizing tasks, see Using custom rule categories.

A.4. Additional Resources

A.4.1. Contributing to the project

To help the Migration Toolkit for Runtimes cover most application constructs and server configurations, including yours, you can help with any of the following items:

  • Send an email to jboss-migration-feedback@redhat.com and let us know what MTR migration rules must cover.
  • Provide example applications to test migration rules.
  • Identify application components and problem areas that might be difficult to migrate:

    • Write a short description of the problem migration areas.
    • Write a brief overview describing how to solve the problem in migration areas.
  • Try Migration Toolkit for Runtimes on your application. Make sure to report any issues you meet.
  • Contribute to the Migration Toolkit for Runtimes rules repository:

    • Write a Migration Toolkit for Runtimes rule to identify or automate a migration process.
    • Create a test for the new rule.

    For more information, see Rule Development Guide.

  • Contribute to the project source code:

    • Create a core rule.
    • Improve MTR performance or efficiency.

Any level of involvement is greatly appreciated!

A.4.3. Reporting issues

MTR uses Jira as its issue tracking system. If you encounter an issue executing MTR, submit a Jira issue.


Revised on 2024-09-12 13:44:58 UTC

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.