studio programacion para móviles libro funciona edición desarrollo curso autocompletar aplicaciones java eclipse version-control netbeans

java - programacion - Para registrar, o no, todo el proyecto Eclipse?



manual de programacion android pdf (12)

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, participé en proyectos en los que se registraba todo el proyecto de Eclipse. Es muy conveniente obtener la configuración del proyecto después de un check-out. Sin embargo, este enfoque aún no estaba libre de problemas:

  • Sospecho fuertemente que algunos archivos de configuración de Eclipse cambiarían sin la interacción del usuario (desde cuando utilicé Eclipse Europa), haciéndolos aparecer como cambiados (ya que fueron cambiados, pero no interactivamente) cuando es hora de hacer una confirmación.
  • Hay 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 enojaría y arruinaría 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, tengo otra razón para no comprometer los archivos del proyecto:

  • Puede haber desarrolladores que prefieran NetBeans que se unirán al proyecto más tarde. Sin embargo, no se unirán en los próximos meses.

¿Cómo organizas 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?

Como respuesta a:

"Hay configuraciones únicas para cada máquina de desarrollo, así como configuraciones globales para todos los desarrolladores en un proyecto. Mantenerlas separadas fue difícil".

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

Ahora, cómo asegurarse de que su sistema de compilación continua comprenda los cambios que se realizaron en la configuración del eclipse, ese es otro problema ... (tengo un build.xml para la hormiga que mantengo actualizado a mano)

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, por lo que, por supuesto, la administració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.

En nuestro mundo, controlamos todo el proyecto Eclipse y todo el proyecto paralelo pero separado de Netbeans. Nuestras motivaciones para esto se centraron completamente en "cuando realice un pago, quiero una configuración funcional inmediatamente después". Esto significa que teníamos que hacer algo de trabajo:

  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. Cree conjuntos de datos editados que no causen que la verificación tarde demasiado (es un gran proyecto).

Esta filosofía valía dinero en efectivo (o al menos horas de trabajo que son casi más valiosas) cuando nuestro nuevo empleado pudo verificar el proyecto de Subversion en Eclipse e inmediatamente ejecutar un sistema funcional con un (pequeño) conjunto de datos reales sin ningún problema. o molestarse por su parte.

Seguimiento : esta filosofía de "hacer que la vida del nuevo tipo sea más fácil" dio sus frutos una vez más cuando cambió IDEs (decidió probar Netbeans después de usar Eclipse durante bastante tiempo y decidió seguir con esto por 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.

Intenta llevar tu proyecto a un sistema de compilación como maven. 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 dar la respuesta a tu 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.

Me gusta comprobar el .project, .classpath y archivos similares solo si son idénticos en cualquier máquina de usuario de Eclipse de todos modos. (Las personas que usan otros IDEs deberían 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 diferentes usuarios que trabajan en el proyecto desean realizar cambios o modificaciones en sus archivos .project o .classpath u otros archivos, le recomiendo que no los controle en el control de código fuente. Solo causará dolores de cabeza a largo plazo.

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

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.

Solo controlo que las cosas las hagan los humanos, cualquier otra cosa que se genere (ya sea de manera automática o no) debería volver a regenerarse fácilmente y es probable que cambie (como ya dijiste). 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?

Sugiero que el sistema de control de versiones ignore los archivos reales del proyecto debido a los inconvenientes que mencionaste.

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 vuelva a copiarla). a 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)

Yo 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 controlo 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 pueda generarse.

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

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 ponerlos 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 plug-in. Por ejemplo, trabajo con Spring, así que siempre compruebo los .springBeans y también para CheckStyle. Siempre compruebo el proyecto .checkstyle .

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

  • .settings / org.eclipse.jdt.ui.prefs - contiene la configuración para el orden de importación
  • .settings / org.eclipse.jdt.core.prefs - contiene la configuración para la versión del compilador

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