Cómo compartir la configuración de Eclipse en diferentes espacios de trabajo

Question

Estoy usando Eclipse (PDT) como IDE principal en diferentes máquinas. (como en casa, computadora portátil, en la oficina, etc.). ¿Cómo podría compartir el Eclipse y la configuración del proyecto pragmáticamente entre varias computadoras? ¿Debería la versión controlarlos, o hay alguna manera más fácil de hacer esto?

¿Cómo se asegura de usar la misma buena y vieja configuración hasta la fecha en todas sus computadoras?

Answer 1

En realidad, puede configurar muchos ajustes específicos del proyecto que pueden controlarse en el control de fuente. Para proyectos pequeños, esto funciona realmente bien. Para proyectos más grandes, decidimos tener un único archivo que utilizamos para todos nuestros proyectos y verificamos en un proyecto separado de "activos" que mantenía las cosas que los desarrolladores necesitaban para comenzar a trabajar en nuestro proyecto. Esto también incluye cosas como licencias y otros archivos necesarios.

Answer 2

Intercambio de eclipsar a los ajustes específicos a través de los espacios de trabajo:

1. Ir a ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings
2. Copiar todo bajo el directorio anterior a ${new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings

Esto va a asegurarse de que el ${new_workspace} es tener la misma configuración que ${old_workspace}

Espero que esto ayude. Actualización en caso de cualquier problema.

Answer 3

Aquí hay dos preguntas. Primero, hay definiciones de proyecto, los archivos .project y configuraciones específicas del proyecto. Personalmente, me gustan los que están en mi control de fuente, ya que hace que revisar un proyecto y configurar un IDE sea mucho más fácil.

En segundo lugar, tiene la configuración del espacio de trabajo. Verás muchas preguntas en esta área. Sugiero echar un vistazo a Pulse: es una distribución Eclipse mejorada que puede, entre otras cosas, guardar la configuración de su espacio de trabajo y sincronizarla con varias máquinas o miembros del equipo.

Answer 4

También puede copiar los archivos de .prefs ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings a una carpeta llamada .settings en la carpeta raíz de su proyecto y luego añadirlo a SVN (o CVS o ...)

De esa manera los ajustes se distribuirse a todos los desarrolladores junto con el código fuente durante una actualización.

Answer 5

Tuve que trabajar en múltiples espacios de trabajo simultáneamente y había muchas preferencias para establecer cada vez que creaba un nuevo espacio de trabajo. Creé un espacio de trabajo de plantilla y creé todas las configuraciones requeridas en ese espacio de trabajo de plantilla. Siempre que creo un nuevo espacio de trabajo, creo un enlace de sim de {new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings para señalar a {template_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings. Por lo tanto, cuando edite cualquier preferencia en cualquiera de los espacios de trabajo, se replicará en todos los demás espacios de trabajo.

Creé este alias de función en mi .profile para que una vez que cree un nuevo espacio de trabajo, ejecute esta función en mi símbolo del sistema con mi nuevo nombre de espacio de trabajo como argumento para que se cree el enlace.

function eclset(){ 
    present_dir=`pwd`; 
    cd {parent_to_workspace}/$1/.metadata/.plugins/org.eclipse.core.runtime ; 
    rm -rf .settings ; 
    ln -s {parent_to_workspace}/template/.metadata/.plugins/org.eclipse.core.runtime/.settings .settings; 
    cd $present_dir; 
} 

Answer 6

Otra opción es la exportación/importación:

1. el espacio de trabajo existente, File->Export...->General->Preferences, control de exportación de todo, y selecciona el archivo para guardarlos en (Preferencias.EPF por ejemplo)
2. inicio de Eclipse en un nuevo espacio de trabajo, File->Import...->General->Preferences, seleccione el archivo (prefs.epf), verificación de la importación de todo

que funcionó muy bien para el autor original de este consejo: él tenía su formato de código , estilo de código, repositorios svn, preferencias jres importadas.

Editar: En Eclipse Juno esto funciona mal. Algunas preferencias silenciosamente no se transfieren, como guardar acciones.

Answer 7

Es un proyecto relativamente nuevo, pero parece que se creó Eclipse Oomph exactamente por esta razón. A través de esta herramienta puede crear una configuración única que se puede compartir con otros. Yo no lo he usado (aún), pero estoy planeando:

https://projects.eclipse.org/projects/tools.oomph

Answer 8

A partir del eclipse de neón (y posiblemente Marte, también), puede copiar los siguientes dos directorios, para compartir su mesa de trabajo y los ajustes/preferencias entre sus diferentes espacios de trabajo:

[workspace]/.metadata/.plugins/org.eclipse.core.runtime/.settings 
    [workspace]/.metadata/.plugins/org.eclipse.e4.workbench 

Answer 9

tuve el mismo problema.

Mi enfoque: el almacenamiento de los datos del proyecto en un directorio gestionados por owncloud

El Proyecto X se crea en la estación de trabajo A, con una ruta personalizada que apunta a un nuevo subdirectorio de mi jerarquía ownCloud. El espacio de trabajo predeterminado sigue residiendo en el sistema de archivos de A.

Cuando estoy sentado en la estación de trabajo BI abre el área de trabajo local predeterminada (local en B) y crea un nuevo proyecto usando las fuentes existentes en ownCloud "sincronizado" directorio.

Simplemente haga clic en Actualizar cada vez que inicie Eclipse y tendrá los datos del proyecto actual. La sincronización se ejecuta en segundo plano automágicamente, así que tenga cuidado cuando haya terminado de trabajar para cerrar el eclipse y le dé a ownCloud la oportunidad de cargar los nuevos archivos en el propio servidor de Cloud.

Tomcat u otros servidores se ejecutan en local, la configuración se copia manualmente entre las máquinas a través de scp. Esto sucede solo si hay cambios en la configuración del servidor, que no es muy frecuente.

No tuve problemas de compatibilidad con NEON 2 (arch linux) & NEON 3 (descargue una ejecución en Debian) con diferentes JDK todavía.

Saludos Armin

Answer 10

simplemente copiar los directorios

${old_workspace}/.metadata/.plugins

de un proyecto existente a la nueva.

Eso funcionó bien en proyectos PHP (bastante simples).