Appendix A. Reference material
A.1. About MTA command-line arguments
The following is a detailed description of the available MTA command line arguments.
To run the MTA command without prompting, for example when executing from a script, you must use the following arguments:
-
--overwrite -
--input -
--target
Example A.1. MTA CLI arguments
| Command | Type | Description |
|---|---|---|
|
| Flag to analyze known open-source libraries. | |
|
| Flag for running multiple analyze commands in bulk, which result in a combined static report. | |
|
| Integer |
Flag to define the number of lines of source code to include in the output for each incident (default: |
|
| String Array | Flag for the directory for dependencies. |
|
| Boolean |
Flag to run default rulesets with analysis (default: |
|
| Flag to output help for analyze | |
|
| String | Flag for Hyper Text Transfer Protocol (HTTP) proxy string URL |
|
| String | Flag for Hypertext Transfer Protocol Secure (HTTPS) proxy string URL |
|
| String |
Flag to select incidents based on custom variables, for example, |
|
| String | Flag for the path to application source code or a binary. For more details, see Specifying the input. |
|
| String | Flag for the jaeger endpoint to collect traces. |
|
| Flag to create analysis and dependency output as JSON. | |
|
| String | Flag to run rules based on a specified label selector expression. |
|
| Flag to list available supported providers. | |
|
| Flag to list rules for available migration sources. | |
|
| Flag to list rules for available migration targets. | |
|
| string | Flag path to a custom Maven settings file to use |
|
| String |
Flag for analysis mode, this must be one of |
|
| String | Flag to excluded URLs from passing through any proxy (relevant only with proxy) |
|
| String | Flag for the path to the directory for analysis output. For more details, see Specifying the output directory. |
|
| String | Flag to override the provider settings. The analysis pod runs on the host network, and no providers are started. |
|
|
Flag to overwrite the output directory. If you do not specify this argument and the | |
|
| String Array | Flag to specify which provider or providers to run. |
|
| String Array |
Flag to specify the filename or directory containing rule files. Use multiple times for additional rules, for example, |
|
| Local flag to run analysis directly on local system without containers (for Java and Maven) | |
|
| Flag to not generate static report. | |
|
| String Array |
Flag for the source technology to consider for analysis. Use multiple times for additional sources, for example, |
|
| String Array |
Flag for the target technology to consider for analysis. Use multiple times for additional targets, for example, |
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
-
--sourceMode: The directory is evaluated as a single application.
-
- File
-
--sourceMode: The file is evaluated as a compressed project.
-
A.1.2. Specifying the output directory
Specify the path to the directory to output the report information generated by MTA.
Usage
--output <OUTPUT_REPORT_DIRECTORY>
-
If omitted, the report will be generated in an
<INPUT_ARCHIVE_OR_DIRECTORY>.reportdirectory. If the output directory exists, you will be prompted with the following question with a default answer 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, MTA 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. You can use this argument, in conjunction with the --target argument, 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 MTA to only run the rulesets matching the specified versions, for example, --source eap:5.
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 Applications 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. You can use this argument, in conjunction with the --source argument, 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 MTA to only run the rulesets matching the specified versions, for example, --target eap:7.
A.2. Supported technology tags
The following technology tags are supported in MTA 7.1.1:
- 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
- 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 Applications 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 MTA uses when estimating the level of effort required for a rule.
| Level of Effort | Story Points | Description |
|---|---|---|
| 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 Applications 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 MTA 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 Applications on your application. Make sure to report any issues you meet.
Contribute to the Migration Toolkit for Applications rules repository:
- Write a Migration Toolkit for Applications 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 MTA performance or efficiency.
Any level of involvement is greatly appreciated!
A.4.2. Migration Toolkit for Applications development resources
Use the following resources to learn and contribute to the Migration Toolkit for Applications development:
- MTA forums: https://developer.jboss.org/en/windup
- Jira issue tracker: https://issues.redhat.com/projects/MTA/issues
- MTA mailing list: jboss-migration-feedback@redhat.com
A.4.3. Reporting issues
MTA uses Jira as its issue tracking system. If you encounter an issue executing MTA, submit a Jira issue.
Revised on 2024-12-07 18:31:25 UTC
