Para registrar, o no, todo el proyecto de Eclipse?

Question

Pronto verifico el primer compromiso de un nuevo proyecto de Java. Trabajo con Eclipse Ganymede y un montón de complementos están haciendo las cosas un poco más fáciles.

Anteriormente, he sido parte de proyectos en los que se ha registrado todo el proyecto de Eclipse. Es muy conveniente obtener la configuración del proyecto después de un check-out. Sin embargo, este enfoque todavía no estaba libre de problemas:

• tengo la fuerte sospecha de que algunos archivos de configuración de Eclipse cambiarían sin interacción del usuario (de cuando solía Eclipse Europa), haciendo que aparezcan como cambiado (ya que se cambiaron, pero no interactivamente) cuando es hora de hacer un commit.
• Existen configuraciones únicas para cada máquina de desarrollo, así como configuraciones globales para todos los desarrolladores en un proyecto. Mantenerlos separados era difícil.
• En algún momento, si la versión de Eclipse era diferente de otras, Eclipse se enojaba y arruinaba la configuración del proyecto. Otro caso es que cambia el formato, por lo que se actualiza y, si se comete, desordena la configuración para otros.

Para este proyecto específico que tienen otra razón para no cometer los archivos de proyecto:

• Puede haber desarrolladores que prefieren NetBeans que formarán parte del proyecto más adelante. Sin embargo, no se unirán en los próximos meses.

¿Cómo se organiza esto? ¿Qué controlas en el control de versiones y qué mantienes al aire libre? ¿Qué considera la mejor práctica en este tipo de situación?

Answer 1

Como mínimo debe registrar los archivos .project y .classpath. Si alguien en su equipo está codificando una ubicación JAR externa en el .classpath, debe colocarlos contra la pared y dispararles. Uso Maven para administrar mis dependencias, pero si no está utilizando maven, debe crear bibliotecas de usuario para sus JAR externos con una convención de nomenclatura coherente.

Después de eso debe considerar las cosas en un complemento por complemento. Por ejemplo, trabajo con Spring, por lo que siempre realizo el check-in en el .springBeans y también para CheckStyle I siempre check-in en el proyecto .checkstyle.

Se pone un poco más complicado cuando se trata de la configuración de la carpeta .settings pero en general el registro de entrada en el siguiente si cambio de la configuración predeterminada para mi proyecto y quiero que ellos comparten con el resto del equipo:

• .settings/org.eclipse.jdt.ui.prefs - que contiene los ajustes para la importación de ordenar
• .settings/org.eclipse.jdt.core.prefs - Contiene la configuración de la compilador versión

En general, no he notado que Ganymede modifique archivos sin que yo modifique las preferencias del proyecto.

Answer 2

Uso IntelliJ, que tiene archivos de proyecto XML. No los reviso, porque cambian con frecuencia y son fáciles de recrear si es necesario.

No reviso los archivos JAR. Guardo esos en un repositorio separado, a la Maven 2.

No controlo WARs o JARs o javadocs o cualquier otra cosa que se pueda generar.

Compruebo en SQL y scripts y la fuente de Java y la configuración XML.

Answer 3

No. Solo verifique el código fuente de sus proyectos.

Answer 4

Solo controlo que los seres humanos lo hagan, cualquier cosa que se genere (ya sea automática o no) debe volver a generarse fácilmente y es probable que cambie (como ya ha dicho). La única excepción a esto es cuando los archivos generados son difíciles (requiere mucha intervención humana;)) para hacerlo bien. ¿Cómo alguna cosa como esta debería ser automatizada de alguna manera?

Answer 5

Sugeriría que el sistema de control de versiones ignore los archivos reales del proyecto debido a las desventajas que mencionó.

Si hay suficiente información consistente en la configuración del proyecto que sería beneficioso tenerla accesible, cópiela en una ubicación que Eclipse no considere especial, y la tendrá disponible para trabajar en el proceso de pago. (y copie nuevamente donde Eclipse le prestará atención).Existe una posibilidad decente de que separar los archivos reales del proyecto de los controlados resulte en la pérdida de sincronía, así que solo sugiero esto si hay un claro beneficio de tener la configuración disponible (o si está seguro de que lo hará). ser capaz de mantenerlos sincronizados)

Answer 6

Me gusta comprobar en .project, .classpath, y archivos similares solo si serán idénticos en cualquier máquina de usuario de Eclipse de todos modos. (Las personas que usan otros IDEs deben poder verificar y crear su proyecto independientemente, pero ese problema es ortogonal a la verificación o no de los archivos de solo Eclipse).

Si los usuarios diferentes que trabajan en el proyecto querrán realizar cambios o ajustes en su .project o .classpath u otros archivos, le recomiendo que no los controle en el control de fuente. Solo causará dolores de cabeza a largo plazo.

Answer 7

Como respuesta a:

". Hay ajustes únicos para cada máquina de desarrollo, así como la configuración global para todos los desarrolladores en un proyecto de mantenimiento de estos aparte era difícil"

Eclipse ofrece varias formas de mantener la configuración local manejable: Java Classpath Variables (Java> Build Path> Classpath Variables) son una, 'Linked Resources' (General> Workspace> Linked Resources) son otras http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm Creando un README indica qué configuraciones configurar antes de construir/ejecutar el proyecto funciona bastante bien en mi opinión.

Ahora cómo asegurarse de que su sistema de integración continua comprende los cambios que se hicieron para la configuración de eclipse, eso es otro tema ... (Tengo un build.xml separado para hormigas que guardo hasta la fecha con la mano)

Answer 8

Recomiendo usar maven para que todo el ciclo de vida esté fuera de cualquier IDE. Puedes crear fácilmente un proyecto de eclipse con él en la línea de comando y puedes usar lo que quieras, si no es eclipse. Tiene sus peculiaridades pero saca mucha amargura cuando se trata de dependencias y administración de compilación.

Answer 9

En nuestro caso, solíamos verificar los archivos del proyecto (.project y .classpath) para facilitar a todos los desarrolladores la creación de su espacio de trabajo del proyecto. Un archivo de preferencias comunes y un conjunto de proyectos de equipo también se ubicaron en el control de código fuente, por lo que la creación de su espacio de trabajo era tan simple como las preferencias de importación y el conjunto de proyectos del equipo de importación. Esto funcionó muy bien, pero depende de que todos tengan un entorno coherente, cualquier personalización debería aplicarse después de que se haya creado el espacio de trabajo básico.

Todavía hacemos esto en su mayor parte, pero ahora se usa Maven, así que, por supuesto, la gestión de la dependencia se maneja a través de Maven. Para evitar información conflictiva, el .project y .classpath se eliminaron del control de código fuente y ahora se generan a través de los objetivos de maven antes de importar el conjunto de proyectos del equipo. Esto permitiría fácilmente diferentes entornos, ya que solo necesitaría scripts para generar las porciones específicas de IDE basadas en la configuración de Maven.

PD: para facilitar el mantenimiento, prefiero que todos utilicen el mismo entorno. Cualquier otra cosa inevitablemente se convierte en un trabajo de mantenimiento a tiempo completo para alguien.

Answer 10

En nuestro mundo, controlamos todo el proyecto Eclipse y todo el proyecto paralelo pero separado de Netbeans. Nuestras motivaciones para esto se centraron por completo en "cuando realice un pago, quiero una configuración funcional inmediatamente después". Esto significa que tuvimos que trabajar:

1. Cree configuraciones ejecutables para cada IDE principal (a las personas les gusta lo que les gusta). Esto incluye la clase principal, el directorio de trabajo, los parámetros de VM, etc.
2. Cree scripts de inicio útiles para todos nuestros escenarios relevantes.
3. Crea conjuntos de datos editados que no causan que el proceso tarde mucho más (es un gran proyecto).

Esta filosofía era dinero en efectivo vale la pena (o al menos las horas de trabajo que son casi más valioso) cuando nuestro nuevo empleado fue capaz de revisar el proyecto de Subversion en Eclipse y ejecutarla de inmediato un sistema funcional con una (pequeño) conjunto de datos reales sin ningún problema o molestia de su parte.

Seguimiento: esta filosofía de "hacer la vida del chico nuevo más fácil" dio sus frutos de nuevo cuando él cambió IDE (decidió probar Netbeans después de usar Eclipse desde hace mucho tiempo y decidió seguir con ella durante un tiempo) No se requirió ninguna configuración en absoluto, él acaba de abrir el proyecto Netbeans en el mismo directorio que Eclipse había estado señalando. Tiempo transcurrido de conmutación: aproximadamente 60 segundos.

Answer 11

Netbeans 6.5 tiene una importación proyecto Eclipse mejorado que se supone para sincronizar los cambios de nuevo a Netbeans Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization

Answer 12

Tratar de puerto su proyecto a un sistema de construcción como experto. Tiene todo lo que necesita para obtener la misma experiencia del proyecto en cada máquina que usa.

Hay complementos para todo. Como el plugin eclipse. Simplemente escribe "mvn eclipse: eclipse" y el complemento genera todo tu proyecto de eclipse listo para trabajar.

Para responder a su pregunta. Nunca revise archivos que su proyecto no esté usando en ningún momento del ciclo de desarrollo. Eso significa que los archivos de metadatos como las propiedades de eclipse, etc. nunca deben registrarse en un SCM.