2010-11-16 19 views
6

Tutti i membri del mio team lavorano con Eclipse. Tuttavia, ognuno ha diverse configurazioni, preferenze e plugin. Qual è il modo migliore per mantenere una linea di base di plug-in, preferenze come lo stile e la formattazione del codice e altre configurazioni per avere un punto di partenza simile, ma per consentire a ciascun membro del team di avere una configurazione specifica.Come gestisco i plugin, le preferenze e la configurazione di eclissi per una squadra?

Sto cercando una soluzione che sia facile da gestire anche, significa che non ci sono troppi file che risiedono in posizioni diverse.

risposta

6

Un approccio semplice per le preferenze è utilizzare File>Import e File>Export, scegliendo General>Preferences, quindi le preferenze che si desidera condividere. Per alcuni dei miei team passati, abbiamo memorizzato le preferenze di base nel controllo di versione.

+0

Grazie, mi sono imbattuto in questo --- era esattamente quello che stavo cercando. Oggi ho ricevuto una nuova finestra di sviluppo e ho dovuto copiare i miei binding/prefs chiave in un'installazione Eclipse incontaminata. Ha funzionato come un fascino ... – evadeflow

2

Utilizziamo un approccio "di base" in cui abbiamo una versione centrale gestita da alcuni membri principali. L'idea è di scaricare la versione, configurarla come si desidera e quindi lo spazio di lavoro E installare impacchettato nella posizione centrale. Inoltre, alcuni plug-in hanno file di configurazione che archiviamo in una posizione centrale e quindi puntiamo alla loro linea di base (modelli, file di formattazione, ecc.).

C'è anche un software commerciale che farà tutto questo per te, se riesco a trovarlo pubblicherò il link.

Spero che questo aiuti.

3

Si consiglia di verificare Pulse. L'ho usato solo in un ambiente standalone, per singolo utente, ma sembra funzionare piuttosto bene. Credo che con le versioni a pagamento puoi gestire le preferenze e le impostazioni dello spazio di lavoro all'interno del tuo gruppo. Potrei provare a convincere la mia compagnia a provarlo presto.

Fondamentalmente, Pulse fornisce un launchpad centrale per Eclipse. Ti permette di creare i profili di installazione di Eclipse che consistono in un'installazione di Eclipse e vari plugin. Dal launchpad, si seleziona un profilo e si installa. Questo scarica Eclipse e i vari plugin in una cartella centrale sulla tua macchina. Quindi imposta una cartella di profilo che collega in qualche modo i plugin specificati per il profilo. Quindi, quando si avvia, si ottengono solo gli elementi nel profilo indipendentemente da ciò che altri profili hanno installato.

-1

È possibile trovare utile questo article from DeveloperWorks. Mostra come gestire i plugin in modo semplice

+0

-1, la cartella di collegamento è un modo legacy per gestire i plug-in nel periodo del gestore aggiornamenti. Non è consigliabile dopo p2 è il gestore di provisioning e potrebbe essere deprecato in futuro. – Kane

1

Ho trovato una soluzione in un altro question sul sito.
Si consiglia un plug-in chiamato workspace mechanic. Sembra che risolva le preferenze e i problemi di configurazione.
Lo sto usando e sembra buono per la configurazione. tuttavia non fornisce una soluzione per i plugin.

0

La parte più importante sono i plug-in su cui si sta lavorando, suppongo. Quello che facciamo è mettere la fonte per tutti i plugin che sono soggetti allo sviluppo nel controllo di revisione, quindi importare i progetti in uno spazio di lavoro di Eclipse nuovo senza copiarli. Questo è probabilmente ovvio.

Un po 'più complicato sono i plugin che fanno parte dell'ambiente di runtime. Abbiamo un progetto speciale (anche sotto controllo di revisione) che contiene quei vasi, organizzati in directory. Alcuni sono di Eclipse, alcuni provengono da Spring, materiale di registrazione ecc.Esiste anche un file di definizione di destinazione, che definisce quale di questi plugin costituisce l'ambiente. Quindi non stai compilando e correndo contro la copia di Eclipse che stai sviluppando, ma un set indipendente di plugin che è definito come la piattaforma di destinazione.

Comprendere e utilizzare una piattaforma di destinazione fa una grande differenza, poiché non importa più quale versione esatta dell'IDE si sta utilizzando - tutti gli sviluppatori si collegheranno e testeranno lo stesso codice. Un buon effetto collaterale è che controlli il sottoinsieme di plugin che fanno parte del tuo prodotto, ed è impossibile inserire accidentalmente 17 nuovi plugin attraverso una nuova dipendenza innocente.

PDE/Build sfortunatamente non è a conoscenza delle definizioni di destinazione, ma il formato del file è abbastanza semplice da comprendere.

Infine, le preferenze e la formattazione ecc. Possono essere esportate in un file e bloccate nel controllo di revisione, se è importante. Le regole di formattazione standard sono utili, immagino.

Problemi correlati