2.2. Global

Lets you configure some global settings that apply to all supported languages.

2.2.1. General

Lets you control some general preferences.

Figure 2.14. General preferences page

General preferences page
Name

The name of the code convention. This should be a short and unique name that easily identifies a code convention.

Description

Stores a short description for the code convention. The optional description may be used to provide a more detailed explanation of a code convention.

The name and description may be inserted into source files during formatting. See Section 2.3, "Environment" for more information.

2.2.1.1. Miscellaneous

Lets you control miscellaneous options that doesn't fit elsewhere.

Force formatting

Jalopy can keep track of which files have been formatted previously (Refer to Section 2.2.2.1, "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.

Test formatting

When enabled, formatting output is not written to disk and/or opened editors are not updated. This may be worthwile 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.6.14, "Code Inspector" for the available style checks).

Refer to Section 2.4.2, "Logging" for more information about the possible logging options.

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.

Since 1.0

Insert trailing newline

If 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.6.11, "Footer" for more information on footers.

2.2.2. Misc

Lets you control miscellaneous settings.

Figure 2.15. General Misc settings page

General Misc settings page
2.2.2.1. History

In order to effectively use formatting of a project with several developers it is nice to be able to only format files which have changed. Jalopy provides two standard checksums to accomplish this. These work by taking a checksum of the file and comparing it to the one found in history. If this checksum is different, the file is parsed and formatted in memory and a new checksum calculated. If the new checksum is different than the checksum for the unformatted file, it is written to disk. This stops files that have just been updated from source control from having being formatted (and time stamps updated).

To enable the history feature, select your preferred checksum method from the combo box on the left. Adler32 is faster, but 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.

Note that the history file will grow over time, especially if one manages several big projects which share the same profile. So the history file could become quite huge. As all history entries are read into memory at startup, it could eat up quite a bit of memory. Therefore a simple history viewer is provided which enables you to selectively remove obsolete entries if the need should arise.

View

You can use the View button to display the history viewer. Entries can be selectively removed via the popup menu.

Directory

To change the directory where the history data is stored, press the Choose... button. A dialog appears that lets you enter a new directory or - in case the history directory was already changed - select one from out of the last 10 chosen history directories.

Figure 2.16. Choose history directory

Choose history directory

Either enter a direcory 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.

Since 1.0.3

2.2.2.2. Backup

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.

Level

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.

Directory

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 2.1.1.6, "Exporting" 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 or in case the backup directory was already changed, select one from out of the last 10 chosen backup directories.

Figure 2.17. Choose backup directory

Choose backup directory
2.2.2.3. Threads

During batch-formatting, Jalopy can divide the work onto several processors and cores to speed up processing. If you run Jalopy on a multi-processor or multi-core system, use the slider to set the corresponding number of processors or cores (or the multiplier when using a multi-processor system with several cores).

2.2.2.4. Force separator

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, Maven and Console Plug-ins preserve the original line separator by default (this may be overriden via the "fileformat" attribute or "format" command-line option). 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).

Since 1.2.1

2.2.3. Auto

Lets you control the auto-format settings.

Figure 2.18. Auto format settings page

Auto format settings page
On save

When enabled, formatting is performed whenever a dirty file is saved. This feature is only available with the Eclipse, IDEA 4.0 or later, JBuilder, JDeveloper, jEdit and NetBeans 4.0 or later Plug-ins.

Since 1.0.3

On commit

When enabled, files are formatted prior to be committed back to the source code management system (SCM).

This feature is only available with IDEA 5.1 or later.

Since 1.8

With project

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!

Since 1.0.2

With external code convention

When you're working with a group of developers, it can be very useful to share specific code conventions with your team. When this option is enabled, Jalopy checks upon every invocation whether any changes to the shared code convention(s) were applied and if so, updates the local profile accordingly before the sources are formatted. This way all members of the team always use the same coding style without any further user intervention required.

Please note that the check box is only available after a code convention has been imported.

Since 1.0