- FAQ 94: What is a plug-in?
- FAQ 95: Do I use plugin or plug-in?
- FAQ 96: What is the plug-in manifest file (plugin.xml)?
- FAQ 97: How do I make my plug-in connect to other plug-ins?
- FAQ 98: What are extensions and extension points?
- FAQ 99: What is an extension point schema?
- FAQ 100: How do I find out more about a certain extension point?
- FAQ 101: When does a plug-in get started?
- FAQ 102: Where do plug-ins store their state?
- FAQ 103: How do I find out the install location of a plug-in?
- FAQ 104: What is the classpath of a plug-in?
- FAQ 105: How do I add a library to the classpath of a plug-in?
- FAQ 106: How can I share a JAR among various plug-ins?
- FAQ 107: How do I use the context class loader in Eclipse?
- FAQ 108: Why doesnt Eclipse play well with Xerces?
- FAQ 109: What is a plug-in fragment?
- FAQ 110: Can fragments be used to patch a plug-in?
- FAQ 111: What is a configuration?
- FAQ 112: How do I find out whether the Eclipse Platform is running?
- FAQ 113: Where does System.out and System.err output go?
- FAQ 114: How do I locate the owner plug-in from a given class?
- FAQ 115: How does OSGi and the new runtime affect me?
- FAQ 116: What is a dynamic plug-in?
- FAQ 117: How do I make my plug-in dynamic enabled?
- FAQ 118: How do I make my plug-in dynamic aware?
This chapter is from the book
This chapter is from the book
This chapter is from the book
FAQ 102: Where do plug-ins store their state?
Plug-ins store data in two standard locations. First, each plug-in has its own install directory that can contain any number of files and folders. The install directory must be treated as read-only, as a multi-user installation of Eclipse will typically use a single install location to serve many users. However, your plug-in can still store read-only information there, such as images, templates, default settings, and documentation.
The second place to store data is the plug-in state location. Each plug-in has within the user’s workspace directory a dedicated subdirectory for storing arbitrary settings and data files. This location is obtained by calling the method getStateLocation on your Plugin instance. Generally, this location should be used only for cached information that can be recomputed when discarded, such as histories and search indexes. Although the platform will never delete files in the plug-in state location, users will often export their projects and preferences into a different workspace and expect to be able to continue working with them.
If you are storing information that the user may want to keep or share, you should either store it in a location of the user’s choosing or put it in the preference store. If you allow the user to choose the location of data, you can always store the location information in a file in the plug-in state location.
Plug-ins can store data that may be shared among several workspaces in two locations. The configuration location is the same for all workspaces launched on a particular configuration of Eclipse plug-ins. You can access the root of this location by using getConfigurationLocation on Platform. The user location is shared by all workspaces launched by a particular user and is accessed by using getUserLocation on Platform.
Here is an example of obtaining a lock on the user location:
Location user = Platform.getUserLocation();
if (user.lock()) {
// read and write files
} else {
// wait until lock is available or fail
}
Note that these locations are accessible to all plug-ins, so make sure that any data stored here is in a unique subdirectory based on your plug-in’s unique ID. Even then, keep in mind that a single user may open multiple workspaces simultaneously that have access to these areas. If you are writing files in these shared locations, you must make sure that you protect read-and-write access by locking the location.
Note
FAQ 103 How do I find out the install location of a plug-in?
FAQ 111 What is a configuration?
FAQ 123 How do I load and save plug-in preferences?