He visto, leído y pensado en diferentes formas de usar espacios de trabajo (por proyecto, por aplicación (multi-ensamblado o no), por lenguaje de programa, por destino (desarrollo web, complementos, ...), y así sucesivamente) y yo Todavía estoy dudando cuál es el mejor enfoque.

De todos modos, ¿puede dar una idea elaborada, pero no de una página, de esto?

Esto implica muchas subpreguntas, por así decirlo, y no sé todas las subpreguntas específicas que debo hacer, porque no estoy seguro de no conocer todos los aspectos del eclipse (y los espacios de trabajo), pero Trataré de dar un ejemplo de lo que estoy buscando:

• ¿Para qué?
  
  • ¿Para qué significaba el desarrollo del eclipse?
  • ¿Qué piensan los demás / la mayoría de las personas?
  • ¿Qué piensas?
  • ...?
• ¿Por qué?
  
  • ¿Hay conflictos de configuración versus compartir méritos?
  • ¿Alguna razón de espacio de archivos?
  • ¿Actuación?
  • ...?

Ah, y estoy hablando del caso de uso mínimo para un desarrollador que usa diferentes lenguajes y protocolos, y NO necesariamente todos en un proyecto (por ejemplo, php, javascript y xml para algunos proyectos, C # para otros, java y SQL para todavía otros, etc.)

Edición 2012-11-27: No me malinterpretes. No dudo del uso de espacios de trabajo, solo quiero usarlo como debe ser o, de lo contrario, si alguien lo piensa mejor. Entonces "¿para qué?" significa: ¿Cuál es el mejor uso? ¿Y por qué?" en realidad apunta al "¿para qué?", ​​en otras palabras: dígame las razones de su respuesta.

Le proporcionaré mi visión de alguien que se siente muy incómodo en el mundo de Java, que supongo que también es su caso.

Lo que es

Un espacio de trabajo es un concepto de agrupación:

1. un conjunto de proyectos (de alguna manera) relacionados
2. alguna configuración perteneciente a todos estos proyectos
3. algunas configuraciones para Eclipse

Esto sucede creando un directorio y colocando dentro de él (no tiene que hacerlo, está hecho para usted) los archivos que logran decirle a Eclipse esta información. Todo lo que tiene que hacer explícitamente es seleccionar la carpeta donde se colocarán estos archivos. Y esta carpeta no necesita ser la misma donde colocas tu código fuente, preferiblemente no lo será.

Explorando cada elemento arriba:

1. un conjunto de proyectos (de alguna manera) relacionados

Eclipse parece estar siempre abierto en asociación con un área de trabajo en particular, es decir, si está en un área de trabajo A y decide cambiar al área de trabajo B (Archivo> Cambiar áreas de trabajo), Eclipse se cerrará y volverá a abrir. Todos los proyectos que estaban asociados con el espacio de trabajo A (y aparecían en el Explorador de proyectos) ya no aparecerán y ahora aparecerán los proyectos asociados con el espacio de trabajo B. Por lo tanto, parece que un proyecto, para estar abierto en Eclipse, DEBE estar asociado a un espacio de trabajo.

Tenga en cuenta que esto no significa que el código fuente del proyecto debe estar dentro del espacio de trabajo. El espacio de trabajo tendrá, de alguna manera, una relación con la ruta física de sus proyectos en su disco (¿alguien sabe cómo? He buscado dentro del espacio de trabajo buscando algún archivo que apunte a las rutas de los proyectos, sin éxito).

De esta manera, un proyecto puede estar dentro de más de 1 espacio de trabajo a la vez. Por lo tanto, parece bueno mantener su espacio de trabajo y su código fuente separados.

2. alguna configuración perteneciente a todos estos proyectos

Escuché que algo, como la versión del compilador de Java (como 1.7, por ejemplo, no sé si 'versión' es la palabra aquí), es una configuración de nivel de espacio de trabajo. Si tiene varios proyectos dentro de su espacio de trabajo y los compila dentro de Eclipse, todos se compilarán con el mismo compilador de Java.

3. algunas configuraciones para Eclipse

Algunas cosas, como las combinaciones de teclas, también se almacenan a nivel de espacio de trabajo. Por lo tanto, si define que ctrl + tab cambiará las pestañas de una manera inteligente (sin apilarlas), esto solo estará vinculado a su espacio de trabajo actual. Si desea utilizar el mismo enlace de teclas en otro espacio de trabajo (¡y creo que lo desea!), Parece que tiene que exportarlos / importarlos entre espacios de trabajo (si eso es cierto, este IDE se creó sobre unas premisas realmente extrañas). Aquí hay un enlace sobre esto .

También parece que los espacios de trabajo no son necesariamente compatibles entre diferentes versiones de Eclipse. Este artículo sugiere que asigne un nombre a sus espacios de trabajo que contengan el nombre de la versión de Eclipse.

Y, lo que es más importante, una vez que elija una carpeta para que sea su espacio de trabajo, no toque ningún archivo allí o se encontrará con algunos problemas.

Cómo creo que es una buena forma de usarlo

(en realidad, mientras escribo esto, no sé cómo usar esto de una buena manera, es por eso que estaba buscando una respuesta, que estoy tratando de reunir aquí)

1. Crea una carpeta para tus proyectos:
   /projects

2. Cree una carpeta para cada proyecto y agrupe los subproyectos de los proyectos dentro de él:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Cree una carpeta separada para sus espacios de trabajo:
   /eclipse-workspaces

4. Crea espacios de trabajo para tus proyectos:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

El objetivo de un espacio de trabajo es agrupar un conjunto de proyectos relacionados que generalmente conforman una aplicación. El marco del espacio de trabajo se reduce al eclipse.core.resourcescomplemento y, naturalmente, por diseño tiene sentido.

Los proyectos tienen naturaleza, los constructores están vinculados a proyectos específicos y, a medida que cambia los recursos en un proyecto, puede ver en tiempo real la compilación u otros problemas en proyectos que están en el mismo espacio de trabajo. Entonces, la estrategia que sugiero es tener diferentes espacios de trabajo para diferentes proyectos en los que trabajas, pero sin un espacio de trabajo en eclipse no habría un concepto de una colección de proyectos y configuraciones y, después de todo, es una herramienta IDE.

Si eso no tiene sentido, pregunte cómo Net Beans o Visual Studio abordan esto. Es el mismo tema. Maven es un buen ejemplo, revisar un grupo de proyectos relacionados con Maven en un espacio de trabajo le permite desarrollar y ver errores en tiempo real. Si no es un espacio de trabajo, ¿qué más sugeriría? Una aplicación RCP puede ser una bestia diferente dependiendo de para qué se use, pero en el verdadero sentido IDE, no sé cuál sería una mejor solución que un espacio de trabajo o contexto de proyectos. Solo mis pensamientos. - Duncan

Básicamente, el alcance de los espacios de trabajo se divide en dos puntos.

El primer punto (y primario) es el eclipse y está relacionado con la configuración y las configuraciones de metadatos (plugin ctr). Cada vez que crea un proyecto, eclipse recopila todas las configuraciones y las almacena en ese espacio de trabajo y si de alguna manera en el mismo espacio de trabajo está presente un proyecto conflictivo, puede perder alguna funcionalidad o incluso la estabilidad de eclipse.

Y segundo (secundario) el punto de estrategia de desarrollo que uno puede adoptar. Una vez que se alcanza el alcance primario (y se domina) y es necesario realizar más ajustes con respecto a las relaciones del proyecto (como bibliotecas, perspectivas, ctr), iniciar espacios de trabajo separados podría ser apropiado en función de los hábitos de desarrollo o los posibles "comportamientos" del lenguaje / marcos. DLTK, por ejemplo, es una bestia que debería estar contenida en una jaula separada. Muchas quejas en los foros por dejar de funcionar (correctamente o nada) y la solución sugerida fue limpiar la configuración del complemento equivalente del espacio de trabajo actual.

Personalmente, descubrí que me inclino más por la distinción del idioma cuando se trata de espacios de trabajo separados, lo que es relevante para los problemas conocidos que se presentan con el estado actual de los complementos. Preferiblemente los mantengo en los números mínimos, ya que esto genera menos frustración cuando los proyectos se vuelven ... abundantes y el control de versiones no es la única versión que mantiene sus proyectos. Finalmente, la velocidad de carga y el rendimiento es un problema que podría surgir si se cargan muchos complementos (innecesarios) debido a la presencia de proyectos irrelevantes. Línea de fondo; no hay una solución para cada uno, no hay una copia maestra que resuelva el problema. Es algo que crece con la experiencia, ¡menos es más!

Aunque he usado Eclipse durante años, esta "respuesta" es solo una conjetura (que intentaré esta noche). Si queda fuera de votación, obviamente estoy equivocado.

Oracle confía en CMake para generar una "Solución" de Visual Studio para su código fuente de MySQL Connector C. Dentro de la Solución hay "Proyectos" que pueden compilarse individualmente o colectivamente (por la Solución). Cada Proyecto tiene su propio archivo MAKE, compilando su parte de la Solución con configuraciones que son diferentes a los otros Proyectos.

Del mismo modo, espero que un espacio de trabajo de Eclipse pueda contener mis proyectos MAKE relacionados (Eclipse), con un proyecto maestro cuyas dependencias compilen los diferentes proyectos MAKE únicos como requisitos previos para construir su "Solución". (La estructura de mi carpeta sería como describe @Rafael).

Así que espero que una buena forma de usar Workspaces sea emular la capacidad de Visual Studio de combinar proyectos diferentes en una solución.