Motivation
Sometimes, it may be desirable to start the Squish IDE with a non-default set of preference settings. Let’s consider a corporate environment where every tester is supposed to work with the same preference settings. To avoid configuration errors, and to help in deploying changes to everyone, the testers should not have to deal with configuring the Squish IDE themselves.
As an example, we want to provide a customization that defines a custom Test Case Template Directory and also enables usage of spaces over tabs when editing.
Definitions
Let’s start with two short definitions, that are needed to better understand what we’re going to do:
Squish IDE is a composition of a lot of Eclipse plugins, or plugins for short. Many of them are part of a standard Eclipse install, while some provide functionality specific to Squish. Each plugin writes its settings to a file in a directory dedicated to that plugin, under the workspace directory.
When Squish IDE is started for the first time, it creates a so-called workspace. That workspace is persistent, so it is picked up again on subsequent starts of the Squish IDE. For this, the workspace, consisting of all preferences and runtime information (e.g. list of opened files), is serialized to disk, into a workspace directory.
A little heads up
This article expects basic knowledge about commandline usage.
As part of this article, we’re not making any changes to the workspace directory. Making changes might corrupt the workspace and make the Squish IDE fail to load it.
Solution
Eclipse, and thus the Squish IDE, allows you to pass settings customizing the behavior via a configuration file. For this, we run the Squish IDE with the -pluginCustomization <settingsFile> switch. The settingsFile can be named and placed arbitrarily, e.g. on a network share.
The custom settings file
All settings defined in the <settingsFile> file have precedence over settings already in an existing workspace, as well as the default settings, in the case where Squish IDE start triggers generation of a new workspace.
For this demonstration, we have two particular preference settings in mind, but anything that can be configured in the Squish IDE preferences can be handled in that file.
Each line represents one setting and is of the form
<plugin ID>/<setting>=<value>
There’s no full listing of all available settings. The source for compiling your own settings file should be an existing Squish IDE workspace, that has the desired changes applied already.
To access those changes, take a look into the directory <workspace>/.metadata/.plugins/org.eclipse.core.runtime/.settings. For each plugin, there is a settings file. We would find the spacesForTabs setting in the file org.eclipse.ui.editors.prefs. We can take the line from that file, prefix it with the plugin ID and put that line into our custom settings file. The plugin ID to use is the above settings file name without the .prefs extension. The same goes for the TemplateDir preference, which we find in the file com.froglogic.squish.ui.prefs. Let’s set this to point to a directory on a network share.
org.eclipse.ui.editors/spacesForTabs=true com.froglogic.squish.ui/com.froglogic.squish.TemplateDir=/networkshare/squish_tc_templates
Telling the IDE about this settings file
Now that we created a settings file containing desired preference values, it’s time to invoke the Squish IDE point it to that file. In a terminal window:
> cd <SQUISHDIR> > ./bin/squishide -pluginCustomization <settingsFile>
Of course, it is also possible to add this command line switch into existing script wrapping the IDE start or desktop shortcuts.
Conclusion
Now, every tester starts Squish IDE with a shared settings file. Since the settings in the file given as -pluginCustomization have precedence over workspace settings, accidental misconfiguration of important settings are gone on the next start of the Squish IDE, and intended changes are automatically available to all clients.
The post Run Squish IDE with custom preferences appeared first on froglogic.