Appendix A. Reference Material

A.1. Windup Command-line Arguments

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

Note

To run the Windup command without prompting, for example when executing from a script, use --batchMode to take the default values for unspecified parameters and --overwrite to force delete the output directory. Also be sure to specify the required --input and --target arguments.

See the description for each argument for more details.

Table A.1. Windup 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.

--batchMode

Flag to specify that Windup 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 Windup in debug mode.

--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 generate a Tattletale report for each application.

--excludePackages

A space-delimited list of packages to exclude from evaluation. For example, entering "com.mycompany.commonutilities" would exclude all classes whose package name begins 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. See the Input File Argument Tables for details.

--exportCSV

Flag to export the report data to a CSV file on your local file system. Windup 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. For details, see Export the Report in CSV Format.

--help

Display the Windup 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. See Specify the Input for more information.

--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 Windup to not delete temporary working files, such as the graph database and unzipped archives. This is useful for debugging purposes.

--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, Windup 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 Windup. See Specify the Output Directory for more information.

--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.

Warning

Be careful not to specify a report output directory that contains important information!

--packages

A space-delimited list of the packages to be evaluated by Windup. It is highly recommended to use this argument. See Select Packages for more information.

--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. See Set the Source Technology for more information.

--sourceMode

Flag to indicate that the application to be evaluated contains source files rather than compiled binaries. See the Input File Argument Tables for details.

--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. See Set the Target Technology for more information.

--userIgnorePath

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

--userRulesDirectory

Specify a location, in addition to WINDUP_HOME/ignore/ and ${user.home}/.windup/rules/, for Windup to look for custom Windup rules. The value can be a directory containing ruleset files or a single ruleset file. The ruleset files must end in .windup.xml.

--version

Display the Windup version.

A.1.1. Specify 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. Specify the Output Directory

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

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, Windup will proceed to delete and recreate the directory. See the description of this argument for more information.

A.1.3. Set 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 Windup 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 for which JBoss EAP version is appropriate for your source platform.

A.1.4. Set 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 Windup 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 for which JBoss EAP version is appropriate for your source platform.

A.1.5. Select Packages

A space-delimited list of the packages to be evaluated by Windup. 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. It is best to provide this argument with one or more packages. For additional tips on how to improve performance, see Optimize Windup Performance.

A.2. Rule Story Points

A.2.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.

Windup 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.2.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 Windup 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.2.3. Task Severity

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 indicate whether a task must be completed or can be postponed.

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 the optimal. If the change is not made at the time of migration, it is recommended to put it on the schedule soon after migration is completed. An example of this would be the upgrade of EJB 2.x code to EJB 3.

For more information on categorizing tasks, see Using Custom Rule Categories in the Windup Rules Development Guide.

A.3. Additional Resources

A.3.1. Get Involved

To help make Windup cover most application constructs and server configurations, including yours, you can help with any of the following items.

  • Send an email to windup-users@lists.jboss.org and let us know what Windup migration rules should cover.
  • Provide example applications to test migration rules.
  • Identify application components and problem areas that may be difficult to migrate.

    • Write a short description of these problem migration areas.
    • Write a brief overview describing how to solve the problem migration areas.
  • Try Windup on your application. Be sure to report any issues you encounter.
  • Contribute to the Windup rules repository.

    • Write a Windup rule to identify or automate a migration process.
    • Create a test for the new rule.
    • Details are provided in the Windup Rules Development Guide.
  • Contribute to the project source code.

    • Create a core rule.
    • Improve Windup performance or efficiency.
    • See the Windup Core Development Guide for information about how to configure your environment and set up the project.

Any level of involvement is greatly appreciated!

A.3.3. Known Windup Issues

You can review known issues for Windup here: Open Windup issues.

A.3.4. Report Issues with Windup

Windup uses JIRA as its issue tracking system. If you encounter an issue executing Windup, please file a JIRA Issue.

Note

If you do not have one already, you must sign up for a JIRA account in order to create a JIRA issue.

A.3.4.1. Create a JIRA Issue

  1. Open a browser and navigate to the JIRA Create Issue page.

    If you have not yet logged in, click the Log In link at the top right side of the page and enter your credentials.

  2. Choose the following options and click the Next button.

    • Project

      For core Windup issues, choose Windup: (WINDUP).

      For issues with Windup rules, choose: Windup rules (WINDUPRULE).

    • Issue Type: Bug
  3. On the next screen complete the following fields.

    • Summary: Enter a brief description of the problem or issue.
    • Environment: Provide the details of your operating system, version of Java, and any other pertinent information.
    • Description: Provide a detailed description of the issue. Be sure to include logs and exceptions traces.
    • Attachment: If the application or archive causing the issue does not contain sensitive information and you are comfortable sharing it with the Windup development team, attach it to the issue using the browse button.
  4. Click the Create button to create the JIRA issue.





Revised on 2017-02-17 00:07:40 EST