In my last post I discussed how to best manage run configurations for Eclipse RCP applications. But there was one related topic I wanted to discuss in more detail, and that is how to manage launch arguments.
What are launch arguments?
Launch arguments are arguments that are added to the command line when you execute your application. These arguments come in two flavors:
- Program arguments – Arguments that are Eclipse-specific. For example, the
-cleanargument will clear the configuration area on startup. - VM arguments – Arguments that make sense to the Java VM. For example, the
-Xmxargument allows you to set the maximum heap size for the VM.
Both of these argument types can be set on the Arguments tab in the Run Configurations dialog.
Launch arguments and the target platform
We oftentimes want to apply the same launch arguments to all of our run configurations, and one way to handle that is to specify them on your target platform. On the Target Platform preference page there is a section where you can add whatever arguments you wish.
The arguments associated with a target platform will be added to run configurations generated from the Manifest Editor. They will not be added to configurations generated by the Product Configuration Editor. Also, because the Manifest Editor link does not regenerate a configuration each time, you will need to explicitly delete a configuration if you want to recreate it using new target platform arguments.
Launch arguments and products
A second way to manage arguments is to add them using the Launching tab of the Product Configuration Editor.
When you add arguments in this way, two things will happen:
- The arguments will be added to your run configurations if you launch using the link in the Product Configuration Editor. Because this link regenerates the run configuration each time, consistent use of the link guarantees that your configuration is in synch with your product definition.
- The arguments will also be added to your deployed application in the form of an INI file. This is a nice feature, but it means that you need to be careful when adding arguments that are only useful during development. For example, you may want to use
-cleanto clear the configuration area when you’re developing, but you probably do not want to ship this argument to your customers.
Launch arguments best practices
My approach is to add arguments using the Product Configuration Editor and to always launch my applications using the link in that editor. This guarantees that my run configurations are always in synch with my product definition. I also take care to not add arguments that would be detrimental to a deployed application. Some, such as -consoleLog, I consider harmless in a deployed app and I just leave those in.
If for some reason I absolutely have to add an argument that should not be deployed, I usually clean it out of the INI file during the build process. It’s pretty rare for me to have to do this, though.