java - ¿Qué pasa con los metadatos del proyecto Eclipse que puedo ignorar de forma segura en Git/Mercurial?
gitignore eclipse (5)
De forma rutinaria mantengo .project y .classpath, no solo son seguros para git, sino también útiles.
.class y .settings están en mi gitignore. Esos son generados y específicos de la persona respectivamente.
Tenemos el código para una aplicación Eclipse RCP en un área de trabajo de Eclipse que contiene múltiples proyectos de Java. Estamos utilizando Mercurial con un simple .hgignore just * .class (pero el mismo problema pertenece a Git).
Incluso un pequeño cambio en el código puede hacer que muchos de los archivos de .metadata cambien.
Me gustaría excluir algunos o todos los .metadata del control de versiones. Si lo excluimos por completo, el espacio de trabajo se pierde.
¿Alguien sabe lo que podemos excluir de manera segura? De forma alternativa, ¿cómo podemos recrearlo si lo llevamos a una nueva computadora?
GitHub mantiene un proyecto comunitario "gitignore" que cataloga las listas de archivos sugeridas para ignorar las distintas plataformas, editores e idiomas: https://github.com/github/gitignore
Eclipse ignora está aquí: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore
(Si hay otras listas de archivos que deberían conocer, ¡hágales saber!)
Los archivos que conozco personalmente son:
- version.ini (no muy emocionante)
- .plugins / org.eclipse.jdt.core / variablesAndContainers.dat (variables classpath)
- .plugins / org.eclipse.core.resources / .projects / * /. location (proyectos en el área de trabajo)
En algún lugar, tengo un espacio de trabajo de Eclipse utilizado para probar algunas herramientas relacionadas con Eclipse que se reducen bastante, pero funciona. Veré si puedo desenterrarlo.
Los metadatos del espacio de trabajo realmente no deberían mantenerse en control de fuente. La configuración básica del espacio de trabajo se puede compartir a través de un conjunto de proyectos de equipo .
Metadatos y espacio de trabajo
Nunca compartiría la carpeta .metadata . De hecho, a menos que tenga un motivo en particular, ni siquiera compartiría la carpeta del espacio de trabajo, sino que compartiría cada proyecto por separado con git. De esta forma, la carpeta .metadata siempre estará en la carpeta principal de tu repositorio git y no tienes que pensar si debes ignorarla de todos modos:
|-- workspace/
| /-- .metadata/
| |-- yourProjectOne/
| | /-- .git/
| | |-- .project
| | |-- src/
| | |-- ...
| |-- yourProjectTwo/
| | /-- .git/
| | |-- .project/
| | |-- src/
| | |-- ...
Proyecto específico
Probablemente siempre deba compartir el archivo .project y nunca .settings/ files. El .classpath puede depender de su entorno pero tampoco le sugiero que lo comparta, ya que puede causar conflictos (por ejemplo, si un usuario usa openjdk y el otro usa sun-jdk. El .settings contiene preferencias y configuraciones para eclipse y cambios mucho, por lo tanto, no debe compartirse. Si importa correctamente el proyecto después de haberlo clonado desde git, tampoco tendrá ningún problema.
La documentación de eclipse indica lo siguiente sobre el archivo .project :
El propósito de este archivo es hacer que el proyecto se autodescriba, de modo que un proyecto que esté comprimido o liberado en un servidor pueda recrearse correctamente en otro espacio de trabajo.
y:
Si se crea un nuevo proyecto en una ubicación que contiene un archivo de descripción de proyecto existente, el contenido de ese archivo de descripción se cumplirá como la descripción del proyecto. Una excepción es que el nombre del proyecto en el archivo se ignorará si no coincide con el nombre del proyecto que se está creando. Si el archivo de descripción en el disco no es válido, la creación del proyecto fallará.
También sugiero usar Maven ya que esto le ahorrará muchos problemas con la administración de dependencias y .classpath
Maven
La principal diferencia con un proyecto Maven es que puedes importar el proyecto como Maven -> "Proyectos Maven existentes" y, por lo tanto, solo necesitas compartir el archivo pom.xml y .project en git. Eclipse creará .classpath, .settings/ files automáticamente. Por lo tanto, obviamente no necesitas compartirlos. Si algo cambia en pom.xml, simplemente ejecuta Maven -> "Actualizar configuración del proyecto" y Maven -> "Actualizar dependencias".
Sin Maven
Debe compartir el archivo .project y no la carpeta .settings/ . Puede considerar compartir .classpath, pero puede generar conflictos tal como se explicó anteriormente. Yo sugeriría no compartirlo tampoco. Use el siguiente método para importar el proyecto:
Después de haber clonado el repositorio de git, puede simplemente usar Importar -> "Proyecto existente desde el espacio de trabajo". Eclipse respetará el archivo .project pero recrea el .classpath y .settings/ archivos. Después de la importación, deberá configurar el classpath a mano desde Eclipse (y cada vez que su equipo quiera usar otra biblioteca).
Si no comparte el archivo .project, entonces no es posible importar el proyecto con Eclipse. Primero tendrá que crear un nuevo proyecto con el asistente del proyecto, y luego puede elegir importar "General-> Sistema de archivos", esto copiará todos los archivos en su espacio de trabajo. Esto probablemente no es lo que quieres, porque significa que no puedes clonar el repositorio de git en el espacio de trabajo, debes clonarlo en otro lugar y luego importarlo desde allí. Por lo tanto, siempre debe compartir el archivo .project.
Por favor, deje un comentario si tiene sugerencias para esta explicación o si no está de acuerdo con ella. Espero que esto ayude a uno u otro.