Es el archivo .settings/org.eclipse.jdt.core.prefs parte del proyecto o es parte de mi personal configuración de eclipse?

Debo agregar a la versión de control?

4 Comentarios

  1. 24

    Sí, usted debe. Si este archivo no está bajo el control de versiones, entonces usted no puede crear reproducable versiones de un mismo proyecto, porque no es autónomo, sino que depende de cada instalación de Eclipse y su configuración.

    Si la importación de este proyecto en otro espacio de trabajo (en su o cualquier otro equipo), se puede comportarse de manera completamente diferente, ya que el compilador de cumplimiento de la configuración, las advertencias del compilador de configuración y un montón de otras cosas que de repente es falta o diferentes. Son altas las posibilidades de que un proyecto de repente muestra advertencias/errores en la nueva área de trabajo, mientras estaba completamente bien antes.

    Nota: todo Esto también requiere que usted en realidad configurar todos Java relacionados con la configuración en las propiedades del Proyecto. Nunca utilizar el compilador de Java de configuración de la Ventana -> Preferencias si desea tener auto-contenido de los proyectos.

    Sólo para dar un ejemplo concreto: Si ha configurado sus proyectos compilador nivel de cumplimiento de Java 6, debido a que usted está usando Java 6 características específicas (como Reemplazar las anotaciones en las interfaces), entonces el proyecto se crear un montón de errores de compilación en otros pueblos de las máquinas. Esto es porque el compilador por defecto nivel de cumplimiento en cada espacio de trabajo de Eclipse Java 1.5, y en Java 1.5 que Anular la anotación simplemente no está permitido.

    Esto no tiene nada que ver con si usted es el desarrollo de código cerrado o abierto de la fuente, como se indica en la otra respuesta.

  2. 13

    Contrario a @nitind la opinión, no. Usted no debe poner ningún IDE ajustes específicos bajo el control de versiones. Excepto que se están desarrollando funciones del IDE o plugins.

    En caso de que realmente han obligatorio de equipo de ancho configuración IDE, poniéndolos bajo el control de versiones sería una buena idea, pero IMO tener obligatorio de equipo de ajustes de todo no es una buena idea en sí misma.

    Para todos los demás casos, compartió la configuración IDE son malos para la portátil construye, incluso con el mismo IDE, e inútil en el mejor de los para los usuarios de otros IDEs.

    EDIT: debo diferenciar, dependiendo del grupo objetivo de su proyecto. Si usted es el desarrollo de un código cerrado producto en un equipo que trabaja con eclipse, y luego, mantener estas preferencias bajo el control de versiones es útil y una buena idea. Si usted es el desarrollo de una biblioteca, abierta o cerrada, la fuente, o un proyecto de código abierto, considero ignorando las preferencias más adecuado y educado.

    EDIT2: me temo que @Bananenweizen es la incomprensión de lo que estoy tratando de decir.

    Sé que estas opciones son el eclipse configuración de compilador. Todavía son específicas de IDE en el sentido de que no tendrán ningún efecto en Netbeans o IntelliJ, ya que no tiene ningún impacto en ant o maven se construye a partir de la línea de comandos.

    Sí, dejando a estos configuración de control de versiones puede traer muchos roja líneas onduladas en eclipse en una máquina diferente. No, si es un proyecto de maven con un conjunto de nivel de fuente por el camino, no estoy seguro acerca de hormiga.

    Eclipse no es la construcción de los proyectos por sí mismo, se construye con la hormiga si es un eclispe o una hormiga proyecto, o con maven si se trata de un proyecto de maven. Ambos ant y maven configuración específica para la versión de código fuente que no dependen de IDEs.

    Y aquí es donde estos valores debe ser – en el fichero build. Y el archivo de construcción deben estar bajo control de código fuente. Las excepciones que he mencionado antes, todavía se aplican.

    • El real archivo mencionado controla el cumplimiento del código de nivel y errores del compilador/configuración de advertencias para el proyecto, como si/cómo informar sin usar los locales, los miembros del sector privado, sin uso importado clases, o no controlada valores nulos. No se trata de los estilos de formato, se trata de cómo rigurosamente desea aplicar compilador de basic-detectable de calidad para cualquier persona que trabaja en ese proyecto. EDIT: este archivo en particular existe sólo porque usted eligió para reemplazar el espacio de trabajo por defecto en el proyecto de la página de propiedades. EDIT: a menos que usted está utilizando Facetas.
    • Sí, tienes razón, no es tan unilateral como yo pensaba. Por favor, consulte la edición
    • Tu post se muestra un error de concepto: Los que no son IDE ajustes específicos. Que podría estar en un IDE formato específico, sino que son un elemento esencial del contenido del proyecto, como la conocida ruta de clase es.
    • Ser seguro, no es un error, es una opinión 🙂 por Favor, consulte la edición.
    • por cierto, «Esas no son IDE ajustes específicos. Que podría estar en un IDE formato específico» es completamente equivocada – la configuración sólo puede aplicarse por el IDE de eclipse, por lo que son específicas de IDE. Tal vez quería decir que en realidad no son la intención de ser específicas de IDE, pero, lamentablemente, son y ese es mi punto.
    • De acuerdo. A veces es difícil conseguir que tales cosas se convierten en inglés, sin perder la intención. Básicamente, quería decir que los valores deben ser compartidos (y debe ser IDE independiente) como la configuración de ruta de clases es, pero, lamentablemente, no existe un formato común.
    • entonces estamos de acuerdo en las causas y no están de acuerdo en las consecuencias. Eso está bien conmigo.

  3. 1

    Aquí está el problema con ponerlo bajo el control de versiones….
    Si importar y abrir un proyecto, Eclipse insiste cuando IProject.abierto(…) se llama en tocar el archivo en el .configuración de carpeta… y esto es antes de que pueda registrar el equipo en el proveedor de IProject objeto. Eso significa que validateEdit no fuego y se obtiene errores molestos si usted haga clic en «sí» o «no» en la ventana emergente preguntando «¿quieres hacer de escritura?» Eso es todo bien y bueno para optimista de bloqueo de archivos de los proveedores, pero no tan grande para la «pesimista» queridos. Para nosotros este es otro eclipse molestia.

    Si es para mí, no es ninguna manera me gustaría poner estos en el control de código fuente.

  4. 0

    La respuesta es «sí», y aquí usted encontrará la motivación y la forma correcta de hacerlo: ver la charla «Cometer IDE archivos de metadatos: los malentendidos, incomprensiones y soluciones.» o busque en la correspondiente diapositivas de EclipseCon Europa 2015 por Aurélien Pupier @apupier (Ingeniero de Software Senior, Eclipse especialista).

Dejar respuesta

Please enter your comment!
Please enter your name here