Ho visto, letto e pensato a diversi modi di utilizzare le aree di lavoro (per progetto, per applicazione (multi-asseted o no), per linguaggio di programma, per target (sviluppo web, plugin, ..) e così via) e I sto ancora dubitando di quale sia l'approccio migliore.

Può comunque dare una visione elaborata, ma non una pagina lunga in questo?

Ciò comporta molte sotto-domande, per così dire, e non conosco tutte le sotto-domande specifiche che dovrei porre, perché non sono sicuro di non conoscere tutti gli aspetti di eclipse (e aree di lavoro), ma Proverò a dare un esempio di ciò che sto cercando:

• Per che cosa?
  
  • Cosa significava che lo sviluppo dell'eclissi doveva essere utilizzato?
  • Cosa pensano gli altri / la maggior parte delle persone?
  • Cosa ne pensi?
  • ...?
• Perché?
  
  • Ci sono conflitti di configurazione rispetto alla condivisione dei meriti?
  • Qualche motivo per lo spazio file?
  • Prestazione?
  • ...?

Oh, e sto parlando del caso d'uso minimo per uno sviluppatore che utilizza linguaggi e protocolli diversi, e NON necessariamente tutti in un progetto (ad esempio php, javascript e xml per alcuni progetti, C # per altri, java e SQL per ancora altri, ecc.)

Modifica 27/11/2012: Non fraintendetemi. Non ho dubbi sull'uso delle aree di lavoro, voglio solo usarlo come dovrebbe essere o altrimenti se qualcuno lo pensasse meglio. Quindi "per cosa?" significa: qual è l'uso migliore? E perché?" in realtà punta sul "che cosa?", in altre parole: dimmi i motivi della tua risposta.

Ti fornirò la mia visione di qualcuno che si sente molto a disagio nel mondo Java, che presumo sia anche il tuo caso.

Cos'è

Uno spazio di lavoro è un concetto di raggruppamento:

1. una serie di progetti (in qualche modo) correlati
2. una configurazione relativa a tutti questi progetti
3. alcune impostazioni per Eclipse stesso

Ciò accade creando una directory e inserendo al suo interno (non devi farlo, è fatto per te) i file che riescono a comunicare a Eclipse queste informazioni. Tutto quello che devi fare esplicitamente è selezionare la cartella in cui verranno posizionati questi file. E questa cartella non deve necessariamente essere la stessa dove hai inserito il codice sorgente, preferibilmente non lo sarà.

Esplorando ogni elemento sopra:

1. una serie di progetti (in qualche modo) correlati

Sembra che Eclipse sia sempre aperto in associazione con un particolare spazio di lavoro, ovvero se ci si trova in uno spazio di lavoro A e si decide di passare allo spazio di lavoro B (File> Cambia spazio di lavoro), Eclipse si chiuderà e si riaprirà. Tutti i progetti associati allo spazio di lavoro A (e che erano visualizzati in Esplora progetti) non verranno più visualizzati e ora verranno visualizzati i progetti associati allo spazio di lavoro B. Quindi sembra che un progetto, per essere aperto in Eclipse, DEVE essere associato ad un'area di lavoro.

Si noti che ciò non significa che il codice sorgente del progetto deve trovarsi all'interno dell'area di lavoro. L'area di lavoro avrà, in qualche modo, una relazione con il percorso fisico dei progetti sul disco (qualcuno sa come? Ho guardato all'interno dell'area di lavoro alla ricerca di un file che punta ai percorsi dei progetti, senza successo).

In questo modo, un progetto può trovarsi in più di 1 area di lavoro alla volta. Quindi sembra bene mantenere separati lo spazio di lavoro e il codice sorgente.

2. una configurazione relativa a tutti questi progetti

Ho sentito che qualcosa, come la versione del compilatore Java (come 1.7, ad esempio - non so se 'versione' è la parola qui), è una configurazione a livello di area di lavoro. Se hai diversi progetti nel tuo spazio di lavoro e li compili all'interno di Eclipse, tutti saranno compilati con lo stesso compilatore Java.

3. alcune impostazioni per Eclipse stesso

Alcune cose come le associazioni dei tasti sono archiviate anche a livello di area di lavoro. Quindi, se si definisce che ctrl + tab cambierà le schede in modo intelligente (non impilandole), questo sarà legato solo allo spazio di lavoro corrente. Se vuoi usare la stessa chiave di associazione in un altro spazio di lavoro (e penso che tu voglia!), Sembra che devi esportarli / importarli tra gli spazi di lavoro (se questo è vero, questo IDE è stato costruito su alcuni locali davvero strani). Ecco un link su questo .

Sembra inoltre che le aree di lavoro non siano necessariamente compatibili tra le diverse versioni di Eclipse. Questo articolo suggerisce di nominare le aree di lavoro contenenti il ​​nome della versione di Eclipse.

E, cosa ancora più importante, una volta scelta una cartella come area di lavoro, non toccare alcun file al suo interno o ci si trova in difficoltà.

Come penso sia un buon modo di usarlo

(in realtà, mentre sto scrivendo questo, non so come usarlo in modo positivo, ecco perché stavo cercando una risposta - che sto cercando di assemblare qui)

1. Crea una cartella per i tuoi progetti:
   /projects

2. Crea una cartella per ciascun progetto e raggruppa i sottoprogetti dei progetti al suo interno:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Crea una cartella separata per le tue aree di lavoro:
   /eclipse-workspaces

4. Crea aree di lavoro per i tuoi progetti:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Il punto centrale di uno spazio di lavoro è raggruppare un insieme di progetti correlati che di solito compongono un'applicazione. Il framework dell'area di lavoro si riduce al eclipse.core.resourcesplug-in e, naturalmente, ha senso.

I progetti hanno natura, i costruttori sono collegati a progetti specifici e mentre si cambiano le risorse in un progetto, è possibile vedere in tempo reale la compilazione o altri problemi nei progetti che si trovano nello stesso spazio di lavoro. Quindi la strategia che suggerisco è di avere diverse aree di lavoro per diversi progetti su cui lavori ma senza uno spazio di lavoro in eclissi non ci sarebbe il concetto di una raccolta di progetti e configurazioni e dopo tutto è uno strumento IDE.

Se ciò non ha senso, chiedi come Net Beans o Visual Studio affrontano questo problema? È lo stesso tema. Maven è un buon esempio, il check-out di un gruppo di progetti Maven correlati in un'area di lavoro consente di sviluppare e visualizzare errori in tempo reale. Se non uno spazio di lavoro cos'altro suggeriresti? Un'applicazione RCP può essere una bestia diversa a seconda di cosa viene utilizzata, ma nel vero senso dell'IDE non so quale sarebbe una soluzione migliore di un'area di lavoro o di un contesto di progetti. Solo i miei pensieri. - Duncan

Fondamentalmente l'ambito delle aree di lavoro è diviso in due punti.

Il primo punto (e primario) è l'eclissi stesso ed è correlato alle impostazioni e alle configurazioni dei metadati (plugin ctr). Ogni volta che crei un progetto, eclipse raccoglie tutte le configurazioni e le memorizza in quell'area di lavoro e se in qualche modo nello stesso spazio di lavoro è presente un progetto in conflitto, potresti perdere alcune funzionalità o persino la stabilità dell'eclissi.

E in secondo luogo (secondario) il punto della strategia di sviluppo che si può adottare. Una volta raggiunto (e padroneggiato) l'ambito primario e occorrendo ulteriori adattamenti per quanto riguarda le relazioni di progetto (come librerie, prospettive ctr), avviare spazi di lavoro separati potrebbe essere appropriato in base alle abitudini di sviluppo o ai possibili "comportamenti" del linguaggio / dei quadri. DLTK per esempio è una bestia che dovrebbe essere contenuta in una gabbia separata. Molte lamentele nei forum hanno smesso di funzionare (correttamente o per niente) e la soluzione suggerita è stata quella di pulire le impostazioni del plug-in equivalente dall'area di lavoro corrente.

Personalmente, mi sono ritrovato più incline alla distinzione linguistica quando si tratta di spazi di lavoro separati che è rilevante per i problemi noti che derivano dallo stato attuale dei plugin. Preferibilmente li mantengo nei numeri minimi in quanto ciò porta a meno frustrazione quando i progetti diventano ... abbondanti e il controllo della versione non è l'unica versione che conservi i tuoi progetti. Infine, la velocità e le prestazioni di caricamento sono un problema che potrebbe sorgere se molti plug-in (non necessari) vengono caricati a causa della presenza di progetti irrilevanti. Linea di fondo; non esiste una soluzione per ognuno, nessuna stampa blu master che risolva il problema. È qualcosa che cresce con l'esperienza, meno è di più però!

Sebbene io abbia usato Eclipse per anni, questa "risposta" è solo una congettura (che proverò stasera). Se viene annullato dall'esistenza, ovviamente mi sbaglio.

Oracle si affida a CMake per generare una "soluzione" di Visual Studio per il codice sorgente di MySQL Connector C. All'interno della Soluzione ci sono "Progetti" che possono essere compilati individualmente o collettivamente (dalla Soluzione). Ogni progetto ha il proprio makefile, compilando la sua parte della soluzione con impostazioni diverse rispetto agli altri progetti.

Allo stesso modo, spero che un Eclipse Workspace possa contenere i miei relativi progetti di makefile (Eclipse), con un progetto master le cui dipendenze compilano i vari progetti con un unico makefile come prerequisiti per costruire la sua "Soluzione". (La mia struttura di cartelle sarebbe come descrive @Rafael).

Quindi spero che un buon modo per usare Workspaces sia emulare la capacità di Visual Studio di combinare progetti diversi in una soluzione.