Preferencia de tienda Eclipse Preferencia

Question

Tengo una aplicación RCP de usuario/ubicación múltiple que actualmente utiliza varias opciones configurables por el usuario. Algunas preferencias son específicas para la estación, algunas son específicas para el usuario.

Las opciones son de un almacén de preferencias que guarda los archivos * .prefs en "workspace.metadata.plugins \ org.eclipse.core.runtime.settings".

Esto estaría bien si solo usáramos una sola máquina/usuario. Pero si un usuario fuera a ir a otra estación, entonces el usuario estaría usando las preferencias que se hayan configurado para esa estación.

¿Es posible especificar otro formulario para persistencia (no archivos)?

Answer 1

Parece que necesita almacenar sus preferencias en una ubicación central que todos los usuarios/máquinas pueden alcanzar. Esto significa que debe implementar su propio IPersistentPreferencesStore. Luego puede anular org.eclipse.jface.preference.PreferencePage#doGetPreferenceStore() para usarlo.

La cuestión más importante es cómo implementar ese almacén de preferencias central, pero eso depende de las tecnologías que esté utilizando. En general, si su proyecto utiliza un servidor central, probablemente deba almacenar allí sus preferencias. Por ejemplo, si su proyecto ya usa una base de datos relacional, una solución sería crear tablas de base de datos apropiadas e implementar IPersistentPreferencesStore para acceder a esas tablas a través de JDBC.

Answer 2

Según la la eclipse wiki, las preferencias son basado en archivos, y se almacena:

• para cada instalación (pero esto puede variar para instalaciones multi-usuario), en los archivos almacenados en <eclipse_home>/eclipse/configuration/.settings/.
  Normalmente hay un archivo por complemento, con una extensión .prefs.
  Tenga en cuenta que muy pocos complementos usan preferencias de instalación amplia.
• para cada espacio de trabajo, en archivos almacenados en <workspace>/.metadata/.plugin/org.eclipse.core.runtime/.settings.
  Normalmente hay un archivo por complemento, con una extensión .prefs.
• para cada proyecto --para ajustes a nivel de proyecto - en los archivos almacenados en un subdirectorio de la carpeta del proyecto .settings

lo tanto, si la opción de archivo está aquí para quedarse, puede que tenga que:

• una exportación/volver a importar los ajustes de la sesión manualmente en un directorio específico del usuario (aburrido)
• o hacer algún tipo de mecanismo automatizado:
  • para exportar la configuración en el registro de usuario (HKEY_CURRENT_USER/Software/MyRCP/...) a la salida de la aplicación, y
  • importarlos mediante la lectura de esas claves de registro y se sobreescriben los ficheros .prefs en el workspace.metadata.plugins\org.eclipse.core.runtime.settings directorio local
• o compartir los configuración a través de algún tipo de enlace específico del usuario (una envoltura alrededor de la puesta en marcha del PCR sería el encargado de hacer el enlace correcto, incluso en Windows with junctions por ejemplo)

Answer 3

debería leer multi-user installs

En nuestro caso, se han separado las preferencias de cada usuario de la configuración de la aplicación mediante el establecimiento de la config.ini para incluir lo siguiente:

osgi.instance.area=@user.home/Application Data/earthrise 
osgi.configuration.area=@user.home/Local Settings/Application Data/earthrise/144/configuration 
osgi.sharedConfiguration.area=c:/program files/earthrise/configuration 
osgi.configuration.cascaded=true 

El resultado de esto es que se almacenan las preferencias establecidas por el usuario en su perfil itinerante, pero los datos de configuración específicos de la aplicación se almacenan en la Configuración local.

Esto no resuelve el problema de tener preferencias de usuario específicas para una estación de trabajo en particular, pero permite que cada usuario tenga sus propias preferencias.

Un problema con esto es que el archivo de registro de errores de eclipse se almacenará en el área de la instancia y se difundirá en su perfil móvil, no es lo que realmente desea. Puede codificar esto en el complemento. Vea la solución en eclipse bugzilla - busque 256502

Answer 4

¡Solo una idea!

Dado que el método load() de PreferenceStore hace:

public void load() throws IOException { 
    FileInputStream in = new FileInputStream(filename); 
    load(in); 
    in.close(); 
} 

y puede crear un PreferenceStore

PreferenceStore(String filename) 

o conjunto su nombre de archivo

public void setFilename(String name) { 
    filename = name; 
} 

que podría estar capaz de "piratear" el nombre del archivo en algún lugar en un servidor compartido (o la carpeta de inicio compartida de los usuarios pe rhaps) ...