Run/Debug Configuration: Grails
This feature is supported in the Ultimate edition only.
Grails run/debug configuration enables you to run and debug the Grails applications, tests and Web tests.
The dialog box consists of the following tabs:
|Module||Select application, for which this run/debug configuration is created. By default, the name of the current module is suggested.|
|Command line||Type a command to execute a particular target, for example, |
Alternatively, you can execute target as described in the section Running Grails Targets.
|VM Options||Specify the string to be passed to the VM for launching the application. This string may contain the options such as |
When specifying the options, follow these rules:
|Environment Variables||Click the Browse button to open the Environment Variables dialog box, where you can create variables and specify their values.|
|Add --classpath|| |
If this check box is selected, it means that the user intends to include the dependency directly, by passing
|Launch browser||By default, this check box is not selected and IntelliJ IDEA uses |
Code Coverage tab
Use this tab to configure code coverage monitoring options.
|Choose code coverage runner||Select the desired code coverage runner.|
|Sampling||Select this option to measure code coverage with minimal slow-down.|
|Tracing||Select this option to collect accurate branch coverage. This mode is available for the IntelliJ IDEA code coverage runner only.|
|Track per test coverage||Select this check box to detect lines covered by one test and all tests covering line. If this check box is selected, becomes available on the toolbar of the coverage statistic pop-up window. |
This option is only available for the Tracing mode of code coverage measurement for the testing run/debug configurations.
Refer to the section Viewing Code Coverage Results.
|Merge data with previous results||When you run your unit testing or application configuration several times, use this item to calculate statistics in the Project View, taking into account the statistics of each time you have run the configuration. |
Finally, the line is considered covered if it is covered at least once.
|Packages and classes to record code coverage data||Click and buttons to specify classes and packages to be measured. You can also remove classes and packages from the list by selecting them in the list and clicking the button.|
| Click this button to define the scope of code coverage analysis. In the Add Pattern dialog box that opens, type the comma-delimited list of Ruby regular expressions, and specify whether the matching files should be included into or excluded from code coverage analysis. |
The patterns defining files to be included into code coverage analysis, are marked with +; the ones to be excluded are marked with -.
Each pattern can be enabled or disabled. To do that, select or clear the check box next to a pattern. By default, all newly created patterns are enabled.
|Click this button to delete the selected pattern from the list.|
|Click this button to change the selected code coverage pattern.|
|Do not use the optimized C runtime||Select this check box to enable the option |
|Enable coverage in test folders.||If this check box is selected, the folders marked as test are included in the code coverage analysis.|
If this check box is not selected, IntelliJ IDEA will use the coverage tool included in the selected Python interpreter.
Refer to the section Code Coverage for details.
Maven Settings Tab
Use this tab to configure Maven settings for running and debugging your application. By default, the Use project settings check box is selected and IntelliJ IDEA uses the default settings specified in your project.
|Work offline||If this option is checked, Maven works in offline mode and uses only those resources that are available locally. |
This option corresponds to the
|Use plugin registry||Check this option to enable referring to the Maven Plugin Registry. |
This option corresponds to the
|Execute goals recursively||If this option is cleared, the build does not recur into the nested projects. |
Clearing this option equals to
|Print exception stack traces||If this option is checked, exception stack traces are generated. |
This option corresponds to the
|Always update snapshots||Select this check box to always update snapshot dependencies.|
|Output level||Select the desired level of the output log, which allows plugins to create messages at levels of debug, info, warn, and error, or disable output log.|
|Checksum policy||Select the desired level of checksum matching while downloading artifacts. You can opt to fails downloading, when checksums do not match (|
|Multiproject build fail policy|| Specify how to treat a failure in a multiproject build. You can choose to: |
|Plugin update policy|| Select plugin update policy from the drop-down list. You can opt to: |
|Threads ||Use this field to set the |
For more information, see parallel builds in Maven 3 feature.
|Maven home directory||Use this drop-down list to select a bundled Maven version that is available (for Maven2, version 2.2.1 and for Maven3, version 3.0.5) or the result of resolved system variables such as |
|User settings file||Specify the file that contains user-specific configuration for Maven in the text field. If you need to specify another file, check the Override option, click the ellipsis button and select the desired file in the Select Maven Settings File dialog.|
|Local repository||By default, the field shows the path to the local directory under the user home that stores the downloads and contains the temporary build artifacts that you have not yet released. If you need to specify another directory, check the Override option, click the ellipsis button and select the desired path in the Select Maven Local Repository dialog.|
|Alt+Insert||Click this button to add a new configuration to the list.|
|Alt+Delete||Click this button to remove the selected configuration from the list.|
|Ctrl+D||Click this button to create a copy of the selected configuration.|
|Edit defaults||Click this button to edit the default configuration templates. The defaults are used for newly created configurations.|
|or||Alt+Up or Alt+Down||Use these buttons to move the selected configuration or folder up and down in the list. |
The order of configurations or folders in the list defines the order in which configurations appear in the Run/Debug drop-down list on the main toolbar.
|Move into new folder / Create new folder||Use this button to create a new folder. |
If one or more run/debug configurations are in focus, the selected run/debug configurations are automatically moved to the newly created folder. If only a category is in focus, an empty folder is created.
Move run/debug configurations to a folder using drag-and-drop, or the buttons.
|Sort configurations||Click this button to sort configurations in alphabetical order.|
|Name||In this text box, specify the name of the current run/debug configuration. This field does not appear for the default run/debug configurations.|
|Defaults||This node in the left-hand pane of the dialog box contains the default run/debug configuration settings. Select the desired configuration to change its default settings in the right-hand pane. The defaults are applied to all newly created run/debug configurations.|
|Share|| Select this check box to make the run/debug configuration available to other team members. |
If the directory-based project format is used, the settings for a run/debug configuration are stored in a separate .xml file in the
If the file-based format is used, the settings are stored in the
This check box is not available when editing the run/debug configuration defaults.
|Single instance only||If this check box is selected, this run/debug configuration cannot be launched more than once. |
Every time a new run/debug configuration is launched, IntelliJ IDEA checks the presence of the other instances of the same run/debug configuration, and displays a confirmation dialog box. If you click OK in the confirmation dialog box, the first instance of the runner will be stopped, and the next one will take its place.
This makes sense when the usage of certain resources can cause conflicts, or when launching two run/debug configurations of the same type consumes too much of the CPU and memory resources.
If this check box is not selected, it is possible to launch as many instances of the runner as required. So doing, each runner will start in its own tab of the Run tool window.
|Before launch||Specify which tasks must be performed before applying the run/debug configuration. The specified tasks are performed in the order they appear in the list. |