programacion - eclipse workspace download

Espacios de trabajo de Eclipse: ¿para qué y por qué? (3)

Básicamente, el alcance del espacio (s) de trabajo se divide en dos puntos.

El primer punto (y primario) es el eclipse y está relacionado con las configuraciones y configuraciones de metadatos (plugin ctr). Cada vez que creas 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 existe un proyecto en conflicto, es posible que pierdas algunas funciones o incluso la estabilidad del eclipse.

Y segundo (secundario) el punto de la estrategia de desarrollo que uno puede adoptar. Una vez que se alcanza (se domina) el alcance primario y se necesitan ajustes adicionales relacionados con las relaciones del proyecto (como bibliotecas, perspectivas ctr), iniciar espacios de trabajo separados podría ser apropiado según los hábitos de desarrollo o posibles "comportamientos" del lenguaje / marco. DLTK para ejemplos es una bestia que debe estar contenida en una jaula separada. Muchas de las quejas en los foros dejaron de funcionar (de manera adecuada o no funcionaron) y la solución sugerida fue limpiar la configuración del complemento equivalente del espacio de trabajo actual.

Personalmente, me he encontrado más inclinado a la distinción de idiomas cuando se trata de espacios de trabajo independientes que son relevantes para problemas conocidos que vienen con el estado actual de los complementos que se utilizan. Preferiblemente los guardo en los números mínimos ya que esto conduce a una menor frustración cuando los proyectos se vuelven ... mucho y el control de la versión no es la única versión que conserva 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 presentación de proyectos irrelevantes. Línea de fondo; no hay una solución única para cada uno, ni una impresión azul maestra que resuelva el problema. Es algo que crece con la experiencia, ¡Menos es más!

He visto, leído y pensado diferentes formas de usar espacios de trabajo (por proyecto, por aplicación (multi-asseted o no), por idioma de programa, por objetivo (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 larga, sobre esto?

Esto implica muchas subpreguntas, por así decirlo, y no conozco todas las subpreguntas específicas que debería formular, porque no estoy seguro de que no conozca 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é fue utilizado el desarrollo del eclipse?
- ¿Qué piensa la mayoría de la gente?
- ¿Qué piensas?
- ...?
¿Por qué?
- ¿Hay conflictos de configuración versus méritos compartidos?
- Cualquier 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 ellos en un solo proyecto (por ejemplo, php, javascript y xml para algunos proyectos, C # para otros, Java y SQL para otros, etc.)

Editar 2012-11-27: No me malinterpreten. No dudo del uso de espacios de trabajo, solo quiero usarlo como debe ser o si alguien lo piensa mejor. Entonces "¿para qué?" significa: ¿Cuál es el mejor uso? ¿Y por qué?" en realidad se enfoca en el "¿para qué?", en otras palabras: dígame los motivos de su respuesta.

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

Lo que es

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

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

Esto ocurre al crear un directorio y poner dentro de él (no tienes que hacerlo, ya está hecho) 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 tiene que ser la misma en la que coloque el código fuente, preferentemente no lo será.

Explorando cada artículo arriba:

un conjunto de (de alguna manera) proyectos relacionados

Eclipse parece abrirse siempre en asociación con un espacio de trabajo particular, es decir, si se encuentra en un área de trabajo A y decide cambiar al área de trabajo B (Archivo> Cambiar espacios de trabajo), Eclipse se cerrará y se volverá a abrir. Todos los proyectos que estaban asociados con el espacio de trabajo A (y que aparecían en el Explorador de proyectos) ya no aparecerán y los proyectos asociados con el espacio de trabajo B ahora aparecerán. Por lo tanto, parece que un proyecto, para abrirse 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, relación con la ruta física de los proyectos en su disco (¿Alguien sabe cómo?) Miré dentro del espacio de trabajo buscando algún archivo que apuntara a las rutas de los proyectos, sin éxito.

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

alguna configuración perteneciente a todos estos proyectos

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

algunas configuraciones para Eclipse

Algunas cosas, como las vinculaciones de teclas, también se almacenan en un nivel de espacio de trabajo. Por lo tanto, si define que la pestaña ctrl + 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 clave en otro espacio de trabajo (¡y creo que quiere!), Parece que tiene que exportarlos / importarlos entre espacios de trabajo (si eso es cierto, este IDE se construyó 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 las diferentes versiones de Eclipse. Este artículo sugiere que nombre sus espacios de trabajo que contengan el nombre de la versión de Eclipse.

Y, lo que es más importante, una vez que elige una carpeta para que sea su área de trabajo, no toque ningún archivo dentro de allí o se encontrará con algún problema.

Como 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 intentando reunir aquí)

Crea una carpeta para tus proyectos:
/projects
Cree una carpeta para cada proyecto y agrupe los subproyectos de los proyectos dentro de ella:
/projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1
Crea una carpeta separada para tus espacios de trabajo:
/eclipse-workspaces
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 suelen formar una aplicación. El marco del espacio de trabajo se reduce al complemento eclipse.core.resources y, naturalmente, tiene sentido desde el punto de vista del diseño.

Los proyectos tienen naturalezas, 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 se encuentran en el mismo espacio de trabajo. Entonces, la estrategia que sugiero es tener diferentes espacios de trabajo para diferentes proyectos en los que trabaje, pero sin un espacio de trabajo en eclipse no existiría el 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 aborda esto? Es el mismo tema. Maven es un buen ejemplo, revisar un grupo de proyectos maven relacionados 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ías? Una aplicación RCP puede ser una bestia diferente según el uso que se le dé, pero en el verdadero sentido IDE no sé cuál sería una solución mejor que un espacio de trabajo o contexto de proyectos. Solo mis pensamientos. - Duncan