Lets you configure the global settings that apply to all supported languages.
Lets you control some general preferences.
The name of the code convention. This should be a short and unique name that easily identifies a code convention.
Stores a short description for the code convention. The optional description may be used to provide a more detailed explanation of a code convention.
Name and description may be inserted into source files during formatting. See Section 2.4, “Environment” for more information.
Lets you control miscellaneous options that doesn’t fit elsewhere.
Jalopy can keep track of which files have been formatted previously (Refer to Section 220.127.116.11, “History” for more information about this feature). If the history is enabled, Jalopy won’t format files that have not changed since the last formatting. However, you can disable this check to force a reformat. For example, you might need to update the copyright notice for the whole code base. Enabling this switch ensures that all source files are always formatted.
When enabled, formatting output is not written to disk and/or opened editors are not updated. This may be worthwhile when you want to determine what files cause warnings or errors during formatting. This way Jalopy can be used somewhat similar to a coding style checker (see Section 2.8.19, “Code Inspector” for the available style checks). This option is mostly useful for batch mode processing, therefore it can be enabled from the Console, Ant or Maven plug-ins directly, and should be normally left disabled here. Refer to Section 2.6.2, “Logging” for more information about the possible logging options.
Insert trailing newline
When enabled, Jalopy inserts an empty line at the end of every file. This may help to avoid problems with certain text formatters and processors. Note that Jalopy always inserts at least one empty line after footers, so there is no real need (but it doesn’t hurt) to check the mark in case footers are used. See Section 2.8.16, “Footer” for more information on footers.
Checkout read-only files
When enabled, Jalopy tries to checkout read-only files when it detects that a file is under source control. Such behavior should be the default with most SCM providers anyway, but if you happen to use a SCM system that does not work this way, this option might come to the rescue. Please note that this feature is currently only available with the Eclipse and IntelliJ IDEA plug-ins.
Keep editor state
When enabled, Jalopy will keep the current editor state when formatting editor contents. If an editor is currently dirty, i.e. contains unsaved changes, Jalopy will only update the editor. Otherwise the file is changed on disk as well. Please note that depending on your IDE an undo might not be possible when this option has been enabled.
Use current file in preview
When enabled, Jalopy will use the source file that is currently opened in the editor as the preview file for the configuration dialog. Otherwise custom code snippets are used instead. The preview uses the actual editor file, not the current editor contents. One therefore needs to persist any changes before they show up in the preview. Please note that you need to close and re-open the configuration dialog before an option change will take effect.
Lets you control miscellaneous settings.
In order to efficiently use formatting of projects with several developers, it is important to be able to only format files which have changed. Jalopy provides a simple way to accomplish this by calculating checksums. This stops formatting files that have just been updated from source control from having being formatted (and time stamps updated) and thus prevents checking-in files that actually weren’t touched by the developer later on.
To enable the history feature, select your preferred checksum method from the
combo box on the left. Adler32 is faster, CRC32 is slightly more accurate.
The history information of previous formatting runs will be saved in a file
“history.dat”. Since Jalopy 1.0.3, you can specify the
directory where the file is actually stored. The default is to store the history
file in the current profile directory.
The history file will grow over time, especially if one manages
several big projects which share the same profile. As all history entries are
read into memory at startup, it could eat up quite a bit of resources. Therefore
a simple history viewer is provided which enables you to selectively remove
obsolete entries if need be.
You can use the View button to display the history viewer. Entries can be selectively removed via the pop-up menu.
To change the directory where the history data is stored, press the Choose... button. A dialog appears that lets you enter a new directory. If the history directory has been already changed earlier, you can select from the last ten locations.
Either enter a directory in the text field directly, or press the Browse... button to invoke a directory browser that lets you search the file system for an existing folder or create a new one.
For security reasons, Jalopy creates a backup copy before it overwrites a file so the file may be restored in case a severe error occurred during the write process. The original file is stored in the backup directory and normally removed after the newly formatted file has been successfully written.
The backup level defines how many numbered backups should be retained (up to 30). The default is to never keep any backups (i.e. the backup level is set to '0'). Use the slider to set the number of backups you want to keep.
Specifies the directory where file backups are stored. You should leave this setting untouched in order to make your code convention portable across different systems and platforms (See Section 18.104.22.168, “Export code convention” for more information about possible portability issues).
To change the backup directory, click on the Choose... button. A dialog appears that lets you enter a new directory. If the backup directory has been already changed earlier, you can select from the last ten locations.
During batch-formatting, Jalopy can divide the work onto several processors and/or cores to speed up processing. If you run Jalopy on a multi-processor or multi-core system, use the slider to set the number of processors or cores Jalopy should utilize.
Lets you specify whether and what line ending character(s) should be forced. Enabling the check box causes the selected line separator to be forced for newly formatted files. You can choose from one of the two common platform styles (Unix, Windows) to enforce a specific line terminator. Or select Platform default if you want to obey the line terminator of your platform. Choosing Preserve original keeps the style of the source files, but please note that Jalopy does not support mixed line separators. It will use the style of the first line separator found in a source file for the complete file!
When left disabled, the default behavior depends on the used plug-in: The Ant, Console and Maven plug-ins preserve the original line separator by default (this may be overridden via the “fileformat” attribute, the “format” command-line option, or the “fileFormat” parameter). The Eclipse 2.x and NetBeans plug-ins preserve the original format, too. All other plug-ins use the corresponding IDE setting (sometimes called line terminator or end-of-line characters).
Lets you specify a specific output encoding to be used to write files. Enabling the check box causes the selected encoding to be forced for newly formatted files. You can either choose from one of the platform supported encodings or specify a specific encoding yourself.
When left disabled, the behavior depends on the used plug-in. When using one of the IDE plug-ins, the file encoding as specified in the IDE would be used. But the Ant, Console or Maven plug-ins would use the platform default encoding instead.
The Non-IDE plug-ins allow you to control input and output encoding via configuration attributes/options. Please refer to the documentation of the individual plug-ins for more information
Lets you control the auto-format settings.
When enabled, formatting is performed whenever a dirty file is saved.
When enabled, files are formatted prior to be committed back to the source code management system (SCM). This feature is currently only available with IDEA 5.1 or later.
On code generation
When enabled, source files are automatically formatted after they were generated from the model. This feature is currently only available with IBM Rational Systems Developer.
When enabled, Jalopy tries to activate the profile with either the same name as or aliased by the current IDE project before a file gets formatted. If no corresponding profile exists for the current IDE project, formatting uses the settings of the active Jalopy profile. Please note that for this feature to work efficiently, all profiles should have their auto-switch option enabled!