|
Search
Table of Contents
|
This page contains reference information about the Java Duplicates Finder Build Runner fields. The Java Duplicates Finder Build Runner is intended for catching similar code fragments and providing a report on discovered repetitive blocks of Java code. The Java Duplicates Finder is based on IntelliJ IDEA capabilities, thus an IntelliJ IDEA project file (.ipr) file is necessary to configure the runner. The Duplicates Finder can also find Java duplicates in projects being built by Maven2.
In this section:
| Option |
Description
|
| Build runner |
Select Duplicates Finder (Java) from the drop-down list. This runner is used for gathering IntelliJ IDEA duplicates results. |
IntelliJ IDEA Project Settings
| Option |
Description
|
| Project file type |
Select a radio button to choose the type of the project (IntelliJ IDEA or Maven2). |
Path to the project |
Use this field to specify the path to the project (pom.xml for Maven2 projects or <projectName>.ipr or directory path for IntelliJ IDEA projects). This build runner requires this information to understand the structure of the project.
 | Specified path can be relative to the project root directory or absolute. If the path is absolute, the project should be accessible under this path on the server and on each of the build agents. |
|
Detect global libraries and module-based JDK in *.iml files
|
If this option is checked, all of the module files will be automatically scanned for references to the global libraries and module JDKs when saved. This helps you ensure all references will be properly resolved.
 | Warning
When this option is selected, the process of opening and saving the build runner settings may become time-consuming, because it involves loading and parsing all project module files. |
|
| Check/Reparse Project |
Pressing this button forces immediate reloading and re-parsing all of the project module files. |
Unresolved Project Modules and Path Variables
This section displays messages when an IntelliJ IDEA module file (.iml) referenced from IPR-file:
- cannot be found
- allows you to enter the values of path variables used in the IPR-file
To refresh values in this section, click the Save button.
| Option |
Description
|
| <path_variable_name> |
This field appears, if the project file contains path macros, defined in the Path Variables dialog of IntelliJ IDEA's Settings dialog. In the Set value to field, specify a path to project resources, to be used on different build agents. |
Project JDKs
This section provides the list of JDKs detected in the project file.
| Option |
Description
|
JDK Home
|
Use this field to specify JDK home for the project.
 | When building with the Ipr runner, this JDK will be used to compile the sources of the corresponding IDEA modules. For Inspections and Duplicate Finder builds, this JDK will be used internally to resolve the Java API used in your project.
To run the build process itself, the JDK specified in the JAVA_HOME environment variable will be used. |
|
JDK jar file patterns
|
Click this link to open a text area, where you can define templates for the jar files of the project JDK. Use Ant rules to define the jar file patterns.
The default value is used for Linux and Windows operating systems:
For Mac OS X, use the following lines:
|
IDEA Home
|
If your project uses the IDEA JDK, specify the location of IDEA's home directory |
| IDEA Jar Files Patterns |
Click this link to open a text area, where you can define templates for the jar files of the IDEA JDK. |
| You can use references to external properties when defining the values, like %system.idea_home% or %env.JDK_1_3%. This will add a requirement for the corresponding property. |
Project Global Libraries
This section appears if your project has references to global libraries (option Detect global libraries and module-based JDK in *.iml files should be enabled).
| Option |
Description
|
| Path to Library |
Use this field to specify root directory that contains library jar files. |
| Library Jar Files Patterns |
Click this link to open a text area, where you can define templates for the jar files of the library (default *.jar) |
| You can use references to external properties when defining the values, like %env.CATALINA_BASE%. This will add a requirement for the corresponding property. |
JVM Settings
| Option |
Description
|
| JVM command line parameters |
Specify the desired Java Virtual Machine parameters, such as maximum heap size or parameters that enable remote debugging. These settings are passed to the JVM used to run your build.
Example:
|
Additional Pre-Processing (Ant)
| Option |
Description
|
| Run before build |
In the appropriate fields, enter the Ant scripts and targets (optional) that you want to run prior to starting the build. |
Duplicate Finder Settings
| Option |
Description
|
Test sources
|
If this option is checked, the test sources will be included in the duplicates analysis.
| Tests contain the test data which can be duplicated. Thus, it does not make much sense to verify tests for duplicates. We recommend you not to select this option to avoid too long builds creation. |
|
Detalization level
|
Use these options to define which elements of the source code should be distinguished when searching for repetitive code fragments. Code fragments can be considered duplicated, if they are structurally similar, but contain different variables, fields, methods, types or literals. Refer to the samples below: |
Distinguish Variables |
If this option is checked, the similar contents with different variable names will be recognized as different. If this option is not checked, such contents will be recognized as duplicated:
|
| Distinguish Fields |
If this option is checked, the similar contents with different field names will be recognized as different. If this option is not checked, such contents will be recognized as duplicated:
|
Distinguish Methods |
If this option is checked, the methods of similar structure will be recognized as different. If this option is not checked, such methods will be recognized as duplicated. In this case, they can be extracted and reused.
Initial version:
After duplicates analysis without distinguishing methods, the duplicated fragments can be extracted:
|
| Distinguish Types |
If this option is checked, the similar code fragments with different type names will be recognized as different. If this option is not checked, such code fragments will be recognized as duplicates.
|
| Distinguish Literals |
If this option is checked, similar line of code with different litarels will be considered different If this option is not checked, such lines will be recognized as duplicates.
|
| Ignore Duplicates with Complexity Simpler Than |
Complexity of the source code is defined by the amount of statements, expressions, declarations and method calls. Complexity of each of them is defined by its cost. Summarized costs of all these elements of the source code fragment yields the total complexity.
Use this field to specify the lowest level of complexity of the source code to be taken into consideration when detecting duplicates. For meaningful results start with value 10.
|
| Ignore Duplicate Subexpressions with Complexity Simpler Than |
Use this field to specify the lowest level of complexity of subexpressions to be taken into consideration when detecting duplicates. |
| Check if Subexpression Can be Extracted |
If this option is checked, the duplicated subexpressions can be extracted.
|
| If you need to restrict the sources scope on which to run the Duplicates runner, you can specify additional JVM parameters (in the JVM command line parameters field).
Example:
- all patters must end with either ** or *
- includes have precedence over excludes
- references to modules can be included as [module_name]/<path_within_module>
|
|