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.
fonte
2010-11-19 09:52:06
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