¿Qué archivos de proyectos de NetBeans deberían pasar al control de código fuente?

Normalmente utilizamos Eclipse para un proyecto Java en particular, pero recientemente importé el proyecto en NetBeans para usar sus funciones de creación de diálogo.¿Qué archivos de proyectos de NetBeans deberían pasar al control de código fuente?

Dado que probablemente voy a volver a este, quería para almacenar los archivos de proyecto de NetBeans en el control de versiones. Sin embargo, no quiero enviar archivos que sean "míos" frente a "proyectos", es decir, archivos con mi propia configuración que entren en conflicto con los de otro usuario.

NetBeans creado la siguiente estructura en el área de proyecto de nivel superior:.

nbbuild 
nb-build.xml 
nbproject 
    <various files> 
    configs 
    private

Claramente nbbuild es construir la salida, por lo que no vamos a entrar en el archivo nb-build.xml parece probable, al igual que la mayoría de nbproject. Sin embargo, nbproject/private sugiere que es "mío". Mira a escondidas en "configuraciones", no me queda claro si eso es mío o proyecto ...

Alguien tiene algunas pautas?

Fuente

2009-08-12 Peter Cardona

El NetBeans knowledge base article on project files & version control analiza los archivos del proyecto NetBeans, con consejos poco claros sobre qué archivos son específicos del proyecto (es decir, se pueden compartir a través del control de la versión) y cuáles son específicos del usuario.

Aquí es la sección de control de versiones:

Si el proyecto está desprotegido de un sistema de control de versiones, los build (o nbbuild), dist (o nbdist), y la nbproject/private carpetas no debe ser revisado en ese sistema de control de versiones.

Si el proyecto está en los sistemas de control de versiones de CVS, Subversion o Mercurial, los archivos "ignorar" apropiados se crean o actualizan para estos directorios cuando se importa el proyecto.

Aunque se debe ignorar nbproject/private, nbproject debe registrarse en el sistema de control de versiones. nbproject contiene metadatos del proyecto que permiten a otros usuarios abrir el proyecto en NetBeans sin tener que importar primero el proyecto.

Fuente

2009-08-12 17:32:37

La tinta provista está rota. Básicamente hace que esta respuesta sea inútil. – Kenneth

Encontró una copia del enlace archivada en https://web.archive.org/web/20090216193025/http://www.netbeans.org/kb/docs/java/import-eclipse.html. – Nathan2055

¿Qué pasa con 'nbactions.xml'? –

Ninguno.

Solo los archivos de origen, los scripts de compilación y la documentación que no se generan automáticamente (por ejemplo, el resultado de herramientas como JavaDoc y Doxygen) deben registrarse en un repositorio. Cosas como archivos de proyecto, binarios y la documentación generada no deben verificarse en.

La razón es doble. En primer lugar, no desea sobrescribir la configuración del proyecto de otro desarrollador con la suya. En segundo lugar, es posible que otros desarrolladores no estén usando el mismo IDE que usted (o incluso un IDE), así que no les dé más de lo que necesitan para compilar (el proyecto o su documentación asociada) o ejecutar el proyecto.

Fuente

2009-08-12 17:01:02

Claramente no va a agregar salida de compilación (incluidos los JavaDocs). Pero dudo que la mejor respuesta sea "ninguna". Cada desarrollador necesitaría configurar localmente configuraciones de proyectos comunes, incluyendo cosas simples como qué directorios son fuente o qué nivel de JDK construir. No compartir ese tipo de información de configuración del proyecto nos prepararía para problemas. Por ejemplo, escribo código que funciona para 1.6 pero nuestro proyecto se envía para 1.5. Lo cometo y rompo la construcción. –

Cuando importo un proyecto con Eclipse, es trivial para mí identificar los directorios de origen y el JDK para construir. Además, debería haber un script de compilación que haga eso por mí, ya que podría no estar usando un IDE en absoluto (sino un editor de texto - Notepad ++, emacs, vim). Cada trabajo que he tenido que utilizó el control de fuente solo comprometió los archivos fuente y la documentación generada por el ser humano en el repositorio y nunca he visto un problema. –

No estoy de acuerdo con esto. Creo que hace las cosas mucho más fáciles si todos los desarrolladores de un proyecto están usando el mismo IDE y la misma versión. Los archivos del proyecto deben estar registrados, esto significa que cada desarrollador no tiene que saltar por los aros configurando su entorno cada vez que necesite trabajar en la fuente. Si todos revisan proyectos y proyectos dependientes y archivos JAR en la misma ubicación o estructura de ruta relativa, entonces deberían poder realizar el pago y hacer clic en compilar en un solo paso. Se desperdicia demasiado tiempo si todos tienen que volver a configurar un proyecto y reparar las dependencias rotas todo el tiempo –

Resulta que ambos Thomas & Petercardona son correctos, en cierto modo. NetBeans recomienda que solo importe código fuente y/o documentación. Oh y la carpeta nbproject pero no las carpetas * nbproject/private **.

Desde el NetBeans Knowledge Base article on importing Eclipse projects:

Consideraciones de control de versiones

Si el proyecto está desprotegido de un sistema de control de versiones , la acumulación (o nbbuild), dist (o nbdist), y las carpetas nbproject/private no deben registrarse en ese sistema de control de versiones .

Si el proyecto está en el CVS, Subversion , o sistemas de control de versiones mercuriales, los archivos correspondientes "ignorar" se crean o se actualizan para estos directorios cuando se importa el proyecto .

Aunque nbproject/privada debe ser ignorado , nbproject se debe comprobar en el sistema de control de versiones. nbproject contiene metadatos del proyecto que permiten a otros usuarios abrir el proyecto en NetBeans sin tener que importar primero el proyecto.

Fuente

2009-08-25 12:26:52

Ese es el mismo enlace que publiqué arriba, ¿no? Creo que hay una distinción entre * importar * solo fuente y * verificar * archivos de proyecto. Mientras lo leí, el primero significa traer archivos al IDE de NetBeans, lo último significa poner los archivos en el control de la versión e incluye los archivos de configuración del proyecto. Mi pregunta fue con respecto a este último. Quiero compartir archivos que controlan cómo se produce la compilación (ubicaciones de jar estandarizadas, nivel jdk), pero no controlo cosas como preferencias de formato, diseños de ventanas IDE, etc. –

Como prueba con Netbeans 6.8, sólo el project.xml, configurations.xml y el makefile principal (el uno personalizable en la dir matriz de la 'nbproject' dir, definiciones de objetivos pre/post) deben ser distribuidos a través de la repositorio. Todos los demás archivos serán automáticamente (re) generados por Netbeans (Makefile-impl.ml, Makefile-variables.ml, todos los Makefile-$CONF, Package-$CONF.bash). El directorio 'privado' también debe ser ignorado, obviamente.

Fuente

2009-12-20 01:09:22

¿Qué archivos de proyectos de NetBeans deberían pasar al control de código fuente?

Respuesta

Cuestiones relacionadas