Persistenza archivio Eclipse Preferenza

Question

Possiedo un'applicazione RCP utente/posizione multipla che attualmente utilizza diverse opzioni configurabili dall'utente. Alcune preferenze sono specifiche per la stazione, alcune sono specifiche per l'utente.

Le opzioni provengono da un archivio di preferenze che salva i file * .prefs in "workspace.metadata.plugins \ org.eclipse.core.runtime.settings".

Questo andrebbe bene se stessimo usando una sola macchina/utente. Ma se un utente dovesse andare su un'altra stazione, l'utente userebbe le preferenze impostate per quella stazione.

È possibile specificare un altro modulo per la persistenza (non i file)?

Answer 1

Sembra che sia necessario memorizzare le preferenze in una posizione centrale accessibile a tutti gli utenti/macchine. Ciò significa che devi implementare il tuo IPersistentPreferencesStore. Quindi è possibile ignorare org.eclipse.jface.preference.PreferencePage#doGetPreferenceStore() per utilizzarlo.

La domanda più grande è come implementare quell'archivio delle preferenze centrale, ma ciò dipende dalle tecnologie che si stanno utilizzando. In generale, se il tuo progetto utilizza un server centrale, probabilmente dovresti memorizzare le tue preferenze lì. Ad esempio, se il progetto utilizza già un database relazionale, una soluzione sarebbe creare tabelle di database appropriate e implementare IPersistentPreferencesStore per accedere a tali tabelle tramite JDBC.

Answer 2

Secondo la la eclipse wiki, le preferenze sono basati su file, e memorizzati:

• per ogni installazione (ma puo 'variare per installazioni multi-utente), in file memorizzati in <eclipse_home>/eclipse/configuration/.settings/.
  Di solito c'è un file per plugin, con un'estensione .prefs.
  Si noti che pochissimi plug-in utilizzano le preferenze dell'intero impianto.
• per ogni area di lavoro, nei file memorizzati in <workspace>/.metadata/.plugin/org.eclipse.core.runtime/.settings.
  Di solito c'è un file per plugin, con un'estensione .prefs.
• per ogni progetto --per impostazioni a livello di progetto - in file memorizzati in un .settings sottodirectory della cartella del progetto

Quindi, se l'opzione del file è qui per restare, potrebbe essere necessario:

• sia export/importare nuovamente le impostazioni della sessione manualmente in una directory specifica dell'utente (noioso)
• o fare un qualche tipo di meccanismo automatico:
  • per esportare le impostazioni di Registro di sistema dell'utente (HKEY_CURRENT_USER/Software/MyRCP/...) all'uscita della richiesta, e
  • importarli leggendo queste chiavi di registro e sovrascrivendo i file .prefs nel locale workspace.metadata.plugins\org.eclipse.core.runtime.settings directory
• o condividere quelle impostazioni attraverso un qualche tipo di collegamento specifico per l'utente (un wrapper per l'avvio della RCP sarebbe incaricato di rendere il collegamento giusto, anche su Windows with junctions per esempio)

Answer 3

si dovrebbe leggere su multi-user installs

Nel nostro caso abbiamo separato le preferenze per utente dalla configurazione dell'applicazione impostando il config.ini per includere quanto segue:

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 

Il risultato di ciò è che le preferenze impostate dall'utente vengono memorizzate nel loro profilo di roaming, ma i dati di configurazione specifici dell'applicazione sono memorizzati nelle Impostazioni locali.

Questo non risolve il problema di avere preferenze utente specifiche per una particolare workstation, ma consente di avere ogni utente con le proprie preferenze.

Un problema con questo è che il file di registro degli errori di eclissi verrà archiviato nell'area dell'istanza e verrà spostato nel proprio profilo di roaming, non proprio quello che si desidera. Puoi codificare tutto ciò nel plug-in. Vedere la soluzione alternativa su eclipse bugzilla - cercare 256502

Answer 4

Solo un pensiero!

Poiché il metodo load() di PreferenceStore fa:

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

e si può creare un PreferenceStore

PreferenceStore(String filename) 

o impostare il nome del file

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

si potrebbe essere in grado di "hackerare" il nome del file in qualche punto su un server condiviso (o gli utenti hanno condiviso la cartella home pe raps) ...