Difference between revisions of "FAQ Where do plug-ins store their state?"

From Eclipsepedia

Jump to: navigation, search
m
m
 
Line 1: Line 1:
Plug-ins store data in two standard locations.  First, each
+
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.
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  
+
The second place to store data is the plug-in state location.  Each plug-in has within the user&#146;s workspace directory a dedicated subdirectory for storing arbitrary settings and data files. This location is obtained by calling the method <tt>getStateLocation</tt> on your <tt>Plugin</tt> 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&#146;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-in has within the user&#146;s workspace
+
directory a dedicated subdirectory for storing arbitrary settings and data files.
+
This location is obtained by calling the method <tt>getStateLocation</tt>
+
on your <tt>Plugin</tt> 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&#146;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  
+
Plug-ins can store data that may be shared among several workspaces in two locations. The <i>configuration location</i> 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 <tt>getConfigurationLocation</tt>
workspaces in two locations. The <i>configuration location</i> is the
+
on <tt>Platform</tt>. The <i>user location</i> is shared by all workspaces launched by a particular user and is accessed by using <tt>getUserLocation</tt> on <tt>Platform</tt>.   
same for all workspaces launched on a particular configuration of Eclipse plug-ins.
+
You can access the root of this location by using <tt>getConfigurationLocation</tt>
+
on <tt>Platform</tt>.
+
The <i>user location</i> is shared by all workspaces launched by a particular user
+
and is accessed by using <tt>getUserLocation</tt> on <tt>Platform</tt>.   
+
  
 
Here is an example of obtaining a lock on the user location:
 
Here is an example of obtaining a lock on the user location:
Line 42: Line 17:
 
</pre>
 
</pre>
  
Note that these locations are accessible to all plug-ins, so  
+
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&#146;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.   
make sure that any data stored here is in a unique
+
subdirectory based on your plug-in&#146;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.   
+
  
 
== See Also: ==
 
== See Also: ==
*[[FAQ_How_do_I_find_out_the_install_location_of_a_plug-in%3F]]
+
*[[FAQ How do I find out the install location of a plug-in?]]
*[[FAQ_What_is_a_configuration%3F]]
+
*[[FAQ What is a configuration?]]
*[[FAQ_How_do_I_load_and_save_plug-in_preferences%3F]]
+
*[[FAQ How do I load and save plug-in preferences?]]
  
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font>
+
{{Template:FAQ_Tagline}}

Latest revision as of 20:28, 19 June 2006

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.

[edit] See Also:


This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.