Spazi di lavoro di Eclipse: per cosa e perché?

Ho visto, letto e pensato a diversi modi di usare gli spazi di lavoro (per progetto, per applicazione (multi-assettato 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 un’elaborata, ma non una visione lunga di questa pagina?

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

  • Per che cosa?
    • Per che cosa ha significato lo sviluppo di Eclipse?
    • Cosa pensano gli altri / la maggior parte della gente?
    • Cosa ne pensi?
    • …?
  • Perché?
    • Ci sono conflitti di configurazione e condivisione di meriti?
    • Qualche motivo per lo spazio per gli archivi?
    • Prestazione?
    • …?

Oh, e sto parlando del caso d’uso minimo per uno sviluppatore che usa linguaggi e protocolli diversi, e NON necessariamente tutti in un progetto (es. Php, javascript e xml per alcuni progetti, C # per gli altri, java e SQL per ancora altri, ecc.)

Modifica 2012-11-27: Non fraintendetemi. Non dubito dell’uso degli spazi di lavoro, voglio solo usarlo come dovrebbe essere o altrimenti se qualcuno lo giudicasse meglio. Quindi “per cosa?” significa: qual è il miglior uso? E perché?” in realtà obiettivi sul “che cosa?”, in altre parole: dimmi i motivi della tua risposta.

L’intero punto di un’area di lavoro consiste nel raggruppare insieme una serie di progetti correlati che solitamente costituiscono un’applicazione. Il framework dello spazio di lavoro si riduce al plug-in eclipse.core.resources e, naturalmente, in base alla progettazione ha senso.

I progetti hanno nature, i builder sono collegati a progetti specifici e quando modifichi le risorse in un progetto puoi vedere in compilazione in tempo reale o altri problemi in progetti che si trovano nello stesso spazio di lavoro. Quindi la strategia che suggerisco è avere spazi di lavoro diversi per i diversi progetti su cui lavori ma senza uno spazio di lavoro in eclipse non ci sarebbe alcun concetto di una collezione di progetti e configurazioni e in fin dei conti si tratta di uno strumento IDE.

Se questo non ha senso chiedere come Net Beans o Visual Studio risolve questo problema? È lo stesso tema. Maven è un buon esempio, la verifica di un gruppo di progetti di maven correlati in un’area di lavoro ti consente di sviluppare e visualizzare gli errori in tempo reale. Se non è uno spazio di lavoro che altro suggeriresti? Un’applicazione RCP può essere una bestia diversa a seconda di cosa è usata, ma nel vero senso dell’IDE non so quale sarebbe una soluzione migliore di uno spazio di lavoro o di un contesto di progetti. Solo i miei pensieri – Duncan

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

Cos’è

Uno spazio di lavoro è un concetto di raggruppamento:

  1. un insieme di (in qualche modo) progetti correlati
  2. alcune configurazioni relative a tutti questi progetti
  3. alcune impostazioni per Eclipse stesso

Questo accade creando una directory e inserendola (non devi farlo, è fatta per te) i file che riescono a comunicare a Eclipse queste informazioni. Tutto quello che devi fare in modo esplicito è selezionare la cartella in cui verranno posizionati questi file. E questa cartella non ha bisogno di essere la stessa dove si inserisce il codice sorgente – preferibilmente non lo sarà.

Esplorando ciascun elemento sopra:

  1. un insieme di (in qualche modo) progetti correlati

Eclipse sembra essere sempre aperto in associazione con un particolare spazio di lavoro, cioè, se ci si trova in uno spazio di lavoro A e si decide di passare all’area di lavoro B (File> Cambia spazio di lavoro), Eclipse si chiuderà e riaprirà. Tutti i progetti associati all’area di lavoro A (che apparivano in Esplora progetti) non verranno più visualizzati e verranno ora visualizzati i progetti associati all’area di lavoro B. Quindi sembra che un progetto, da aprire in Eclipse, DEVE essere associato a uno spazio di lavoro.

Si noti che questo non significa che il codice sorgente del progetto deve essere all’interno dell’area di lavoro. Lo spazio di lavoro, in qualche modo, avrà una relazione con il percorso fisico dei tuoi progetti nel tuo disco (chiunque sa come? Ho guardato all’interno dell’area di lavoro alla ricerca di qualche file che punta ai percorsi dei progetti, senza successo).

In questo modo, un progetto può trovarsi all’interno di più di uno spazio di lavoro alla volta. Quindi sembra bello mantenere il tuo spazio di lavoro e il tuo codice sorgente separati.

  1. alcune configurazioni relative a tutti questi progetti

Ho sentito qualcosa, come la versione del compilatore Java (come 1.7, ad esempio – non so se “version” è la parola qui), è una configurazione a livello di area di lavoro. Se hai diversi progetti all’interno dell’area di lavoro e li compili all’interno di Eclipse, tutti verranno compilati con lo stesso compilatore Java.

  1. alcune impostazioni per Eclipse stesso

Alcune cose come le associazioni dei tasti sono memorizzate anche a livello di spazio di lavoro. Quindi, se si definisce che ctrl + tab cambierà tabs in modo intelligente (non li impilerà), questo sarà solo associato allo spazio di lavoro corrente. Se si desidera utilizzare la stessa associazione di tasti in un altro spazio di lavoro (e penso che si desideri!), Sembra che sia necessario esportarli / importarli tra aree di lavoro (se questo è vero, questo IDE è stato creato su alcune premesse davvero strane). Ecco un link su questo .

Sembra anche che gli spazi 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 più importante, una volta che scegli una cartella come area di lavoro, non toccare alcun file all’interno o ci sono problemi.

Come penso sia un buon modo per 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 ogni progetto e raggruppa i sottoprogetti dei progetti all’interno di esso:
    /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 spazi di lavoro per i tuoi progetti:
    /eclipse-workspaces/proj1
    /eclipse-workspaces/proj2

Fondamentalmente l’ambito dello spazio di lavoro (i) è diviso in due punti.

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

E secondo (secondario) il punto della strategia di sviluppo che si può adottare. Una volta che lo scopo primario è soddisfatto (e padroneggiato) e c’è bisogno di ulteriori aggiustamenti per quanto riguarda le relazioni di progetto (come librerie, prospettive ctr), avviare aree di lavoro separate potrebbe essere appropriato in base alle abitudini di sviluppo o possibili “comportamenti” linguistici. DLTK per gli esempi è una bestia che dovrebbe essere contenuta in una gabbia separata. Un sacco di lamentele nei forum perché ha smesso di funzionare (correttamente o per niente) e la soluzione suggerita era quella di pulire le impostazioni del plugin equivalente dallo spazio di lavoro corrente.

Personalmente, mi sono trovato più incline alla distinzione linguistica quando si tratta di aree di lavoro separate che sono rilevanti per i problemi noti che vengono forniti con lo stato corrente dei plugin. Preferibilmente li tengo nei numeri minimi in quanto ciò porta a una minore frustrazione quando i progetti sono diventati … l’abbondanza e il controllo della versione non sono l’unica versione in cui si tengono i progetti. Infine, la velocità e le prestazioni di caricamento rappresentano un problema che potrebbe verificarsi se vengono caricati molti plug-in (inutili) a causa di presentazioni di progetti non pertinenti. Linea di fondo; non esiste una soluzione a tutti, nessuna stampa blu principale che risolva il problema. È qualcosa che cresce con l’esperienza, Less is more but!