Community
Participate
Working Groups
Currently the default instance and configuraiton locations are relative to the eclipse install location. This has long been problematic for shared installs as well as unix users where programs are installed by different users. The current behaviour is to compute the config location relative ot the install if it is writable. If it is not, a location based on the user.home system property is used. The instance location is either in the install dir or you have to spec -data. Proposal: The default for both should be somewhere relative to the user.home property. Specifically, the values found in .eclipseproduct in the install will be used to get <user.home>/<some qualifier path> as the base on which to compute "user relative" locations for config and instance. The path qualifier is read/computed from the .eclipseproduct file as follows: id=some.id version=some.version.number user.root= [ @computed | @install | <relative path> | <absolute path> ] @computed = use the id and version information from the .eclipseproduct file to compute a qualifier of the form <id>_<version>. This is the default behaivour if the user.root property is not specified in .eclipseproduct. @install = use the eclipse install dir path as the base for the user root. that is, the result would be <user.dir>/d__/eclipse. <id> and <version> are ignored. <relative path> = append the given value to <user.home> system property <absolute path> = use this value directly. In the Eclipse .eclipseproduct we would set user.root=@install. The version number in .eclipseproducts does not change from build to build so otherwise multiple eclipse installs would fight for the same config/workspace locations. Using @install ties the config/workspace location to the install location. Downsides: - if the install is moved, the configuration/workspace become decoupled. - path may be long depending on install path Summary: With these changes the default configuration area is in <user.home>/d__/m7/eclipse/configuration The default workspace is in <user.home>/d__/m7/eclipse/workspace Note that the UI team has added a workspace prompter which asks the user for a workspace location when they start eclipse. The use of -data should deminish and users running with no arguments will still be in control of their workspace location.
Rather than changing the defaults for Eclipse, we have introduced the ability for users/product packagers to defined the defaults. The key is the config.ini file found in the configuration area of an install. As shipped in Eclipse, config.ini does not contain any of the keys discussed below. As such, the original default algorithm for locating the config dir is used (i.e, use the install location if writable, otherwise go to the someplace in the user home dir based on the values in .eclipseproduct file). The runtime first consults the base configuration information. Typically this is found in <eclipse>/configuration/config.ini though this is controlled via the osgi.baseConfiguration.area system property (where the value is a file path or URL). If this file contains osgi.configuration.area=<some location> then the given location is used as the local configuration location. The location can be a file path, URL or one of @user.dir or @user.home. The latter two values resolve to the valued of the respective system properites. To this is added a set of sub dirs based again on the values in .eclipseproduct. This local configuration locaoitn is used to store the writeable part of the configuraiton. Shared installs should use @user.home. The current default is effectively @user.dir (assuming the current working dir is "eclipse" when the system is started). The parent of the local configuraiton location is the shared configuration area. By default this is the configuration dir in the eclipse install. The location of this shared config data is controled by a further property osgi.sharedConfiguration.area=<location> where location is a file path or URL for the read only configuration area. The local configuration area's config.ini is free to set the value of this property. Note that if osgi.configuration.cascaded="false" the local configuration has no parent. Using the outlined mechanisms, users or product packagers can setup their systesm to put configuration info in a wide range of locations. The defaults for the workspace are not being changed since the UI team recently introduced the workspace location prompter. Products or users wishing to set the location can use the osgi.instance.area property set in a config.ini files and provide a value of either - an actual file path or URL - @none if none is desired - @noDefault if you want to force it to be set explicitl - @user.dir for somewhere in the current dir (equivalent to the current behaviour) - @user.home to put the workspace in the uesrs's directory under a location based on the values in .eclipseproduct This should be enough configurability to keep people busy for a while.
