Eu vi, li e pensei em diferentes maneiras de usar áreas de trabalho (por projeto, por aplicativo (com várias atribuições ou não), por linguagem de programa, por destino (desenvolvimento web, plugins, etc.) e assim por diante) e eu ainda estou duvidando de qual é a melhor abordagem.

De qualquer maneira, pode dar uma visão elaborada, mas não longa, da página sobre isso?

Isso envolve muitas sub-perguntas, por assim dizer, e não conheço todas as sub-perguntas específicas que devo perguntar, porque não tenho certeza de que não conheço todos os aspectos do eclipse (e áreas de trabalho), mas Vou tentar dar um exemplo do que estou procurando:

• Pelo que?
  
  • Para que o desenvolvimento do eclipse significa que ele é usado?
  • O que as outras / a maioria das pessoas pensa?
  • O que você acha?
  • ...?
• Por quê?
  
  • Existem conflitos de configuração x méritos de compartilhamento?
  • Algum motivo para o espaço no arquivo?
  • Atuação?
  • ...?

Ah, e eu estou falando do caso de uso mínimo para um desenvolvedor que usa diferentes idiomas e protocolos, e NÃO necessariamente todos eles em um projeto (por exemplo, php, javascript e xml para alguns projetos, C # para outros, java e SQL para ainda outros, etc.)

Edit 2012-11-27: Não me interpretem mal. Não duvido do uso de espaços de trabalho, só quero usá-lo como deve ser ou de outra forma, se alguém achar melhor. Então "para quê?" significa: Qual é o melhor uso? E porque?" realmente segmenta o "para quê?", em outras palavras: diga-me os motivos da sua resposta.

Fornecerei a minha visão de alguém que se sente muito desconfortável no mundo Java, o que suponho que também seja o seu caso.

O que é isso

Um espaço de trabalho é um conceito de agrupamento:

1. um conjunto de (de alguma forma) projetos relacionados
2. alguma configuração referente a todos esses projetos
3. algumas configurações para o próprio Eclipse

Isso acontece criando um diretório e colocando dentro dele (você não precisa fazê-lo, é feito para você) arquivos que conseguem informar essas informações ao Eclipse. Tudo o que você precisa fazer explicitamente é selecionar a pasta onde esses arquivos serão colocados. E essa pasta não precisa ser a mesma onde você coloca seu código-fonte - preferencialmente não será.

Explorando cada item acima:

1. um conjunto de (de alguma forma) projetos relacionados

O Eclipse parece sempre ser aberto em associação com uma área de trabalho específica, ou seja, se você estiver em uma área de trabalho A e decidir mudar para a área de trabalho B (Arquivo> Alternar Áreas de Trabalho), o Eclipse se fechará e reabrirá. Todos os projetos que foram associados à área de trabalho A (e estavam aparecendo no Project Explorer) não aparecerão mais e os projetos associados à área de trabalho B serão exibidos. Portanto, parece que um projeto, para ser aberto no Eclipse, DEVE estar associado a um espaço de trabalho.

Observe que isso não significa que o código-fonte do projeto deve estar dentro da área de trabalho. De alguma forma, o espaço de trabalho terá uma relação com o caminho físico dos seus projetos em seu disco (alguém sabe como? Eu procurei dentro do espaço de trabalho procurando algum arquivo apontando para os caminhos do projeto, sem êxito).

Dessa forma, um projeto pode estar dentro de mais de 1 espaço de trabalho por vez. Portanto, parece bom manter seu espaço de trabalho e seu código fonte separados.

2. alguma configuração referente a todos esses projetos

Ouvi dizer que algo, como a versão do compilador Java (como 1.7, por exemplo - não sei se 'version' é a palavra aqui), é uma configuração no nível da área de trabalho. Se você possui vários projetos em sua área de trabalho e os compila no Eclipse, todos eles serão compilados com o mesmo compilador Java.

3. algumas configurações para o próprio Eclipse

Algumas coisas como suas ligações de teclas também são armazenadas no nível da área de trabalho. Portanto, se você definir que ctrl + tab alternará as guias de maneira inteligente (sem empilhá-las), isso será vinculado apenas ao seu espaço de trabalho atual. Se você deseja usar a mesma ligação de chave em outro espaço de trabalho (e acho que deseja!), Parece que você precisa exportar / importar entre espaços de trabalho (se isso for verdade, esse IDE foi construído sobre algumas premissas realmente estranhas). Aqui está um link sobre isso .

Parece também que os espaços de trabalho não são necessariamente compatíveis entre diferentes versões do Eclipse. Este artigo sugere que você nomeie seus espaços de trabalho que contêm o nome da versão do Eclipse.

E, mais importante, depois de escolher uma pasta para ser sua área de trabalho, não toque em nenhum arquivo lá dentro ou você estará com problemas.

Como eu acho que é uma boa maneira de usá-lo

(na verdade, enquanto escrevo isso, não sei como usá-lo de uma maneira boa, é por isso que estava procurando uma resposta - que estou tentando montar aqui)

1. Crie uma pasta para seus projetos:
   /projects

2. Crie uma pasta para cada projeto e agrupe os subprojetos dos projetos:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Crie uma pasta separada para seus espaços de trabalho:
   /eclipse-workspaces

4. Crie áreas de trabalho para seus projetos:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

O objetivo de um espaço de trabalho é agrupar um conjunto de projetos relacionados que geralmente compõem um aplicativo. A estrutura da área de trabalho se resume ao eclipse.core.resourcesplug-in e, naturalmente, por design faz sentido.

Os projetos têm naturezas, os construtores são anexados a projetos específicos e, conforme você altera os recursos em um projeto, é possível ver em tempo real a compilação ou outros problemas em projetos que estão no mesmo espaço de trabalho. Portanto, a estratégia que sugiro é ter diferentes áreas de trabalho para diferentes projetos nos quais você trabalha, mas sem uma área de trabalho no eclipse, não haveria conceito de uma coleção de projetos e configurações e, afinal, é uma ferramenta IDE.

Se isso não faz sentido, pergunte como o Net Beans ou o Visual Studio lida com isso. É o mesmo tema. O Maven é um bom exemplo: verificar um grupo de projetos relacionados a um espaço de trabalho permite desenvolver e ver erros em tempo real. Se não for um espaço de trabalho, o que mais você sugeriria? Um aplicativo RCP pode ser um animal diferente, dependendo do que é usado, mas no verdadeiro sentido do IDE, não sei qual seria uma solução melhor do que uma área de trabalho ou contexto de projetos. Apenas meus pensamentos. - Duncan

Basicamente, o escopo da (s) área (s) de trabalho é dividido em dois pontos.

O primeiro ponto (e primário) é o eclipse e está relacionado às definições e configurações de metadados (plugin ctr). Cada vez que você cria um projeto, o eclipse coleta todas as configurações e as armazena nesse espaço de trabalho e, se de alguma forma no mesmo espaço de trabalho estiver presente um projeto conflitante, você poderá perder alguma funcionalidade ou mesmo a estabilidade do eclipse.

E segundo (secundário), o ponto da estratégia de desenvolvimento que se pode adotar. Depois que o escopo principal for atendido (e dominado) e houver necessidade de mais ajustes em relação às relações do projeto (como bibliotecas, perspectivas ctr), inicie áreas de trabalho separadas que possam ser apropriadas com base em hábitos de desenvolvimento ou possíveis "comportamentos" da linguagem / estrutura. O DLTK, por exemplo, é um animal que deve estar contido em uma gaiola separada. Muitas reclamações nos fóruns pararam de funcionar (de maneira adequada ou não) e a solução sugerida foi limpar as configurações do plug-in equivalente do espaço de trabalho atual.

Pessoalmente, eu me apaixonei mais pela distinção de idioma quando se trata de espaços de trabalho separados, o que é relevante para problemas conhecidos que acompanham o estado atual dos plugins. De preferência, eu os mantenho no número mínimo, pois isso leva a menos frustração quando os projetos se tornam ... bastante e o controle de versão não é a única versão em que você mantém seus projetos. Por fim, a velocidade e o desempenho do carregamento é um problema que pode surgir se muitos plugins (desnecessários) forem carregados devido a projetos irrelevantes. Linha inferior; não existe uma solução única para cada um, nem uma cópia principal que resolva o problema. É algo que cresce com a experiência, menos é mais!

Embora eu use o Eclipse há anos, essa "resposta" é apenas uma conjectura (que vou tentar esta noite). Se a sua existência for eliminada, então obviamente eu estou errado.

A Oracle confia no CMake para gerar uma "Solução" do Visual Studio para o código-fonte do MySQL Connector C. Dentro da solução existem "projetos" que podem ser compilados individualmente ou coletivamente (pela solução). Cada projeto tem seu próprio makefile, compilando sua parte da solução com configurações diferentes dos outros projetos.

Da mesma forma, espero que um Espaço de Trabalho do Eclipse possa conter meus Projetos de makefile relacionados (Eclipse), com um Projeto mestre cujas dependências compilem os vários Projetos de makefile exclusivos como pré-requisitos para a construção de sua "Solução". (Minha estrutura de pastas seria como @Rafael descreve).

Portanto, espero que uma boa maneira de usar os Espaços de Trabalho seja emular a capacidade do Visual Studio de combinar Projetos diferentes em uma Solução.