Pregunta

¿Cómo se asegura de poder verificar el código en Eclipse o NetBeans y trabajar allí con él?

Editar:Si no registra archivos relacionados con ide, debe reconfigurar buildpath, inclusiones y todo eso, cada vez que verifica el proyecto.No sé si ant (especialmente un archivo de compilación ant que se crea/exporta desde eclipse) funcionará con otra idea sin problemas.

¿Fue útil?

Solución

La respuesta inteligente es "al hacerlo": a menos que no esté trabajando con varios IDE, no sabe si está realmente preparado para trabajar con varios IDE.Honesto.:)

Siempre he considerado que las plataformas múltiples son más engorrosas, ya que pueden usar diferentes estándares de codificación (p. ej.Windows puede utilizar de forma predeterminada ISO-8859-1, Linux, UTF-8); para mí, la codificación ha causado muchos más problemas que los IDE.

Algunos consejos más:

  • Quizás quieras ir con Maven (http://maven.apache.org), déjelo generar archivos IDE específicos y nunca los envíe al control de fuente.
  • Para estar seguro de que está generando los artefactos correctos, debe tener un servidor dedicado que cree sus entregables (p. ej.cruisecontrol), ya sea con la ayuda de ant, maven o cualquier otra herramienta.Estos entregables son los que se prueban fuera de las máquinas de desarrollo.Excelente manera de concienciar a la gente de que existe otro mundo fuera de su propia máquina.
  • Prohibir que cualquier ruta específica de la máquina esté contenida en cualquier archivo IDE específico que se encuentre en el control de código fuente.Siempre haga referencia a bibliotecas externas por nombres de rutas lógicas, preferiblemente que contengan su versión (si no usa maven)

Otros consejos

De hecho, mantenemos un proyecto Netbeans y Eclipse para nuestro código en SVN en este momento sin ningún problema.Los archivos de Netbeans no pisan los archivos de Eclipse.Tenemos nuestros proyectos estructurados así:

sample-project   
+ bin
+ launches  
+ lib  
+ logs
+ nbproject  
+ src  
  + java
.classpath
.project
build.xml

Los puntos más importantes parecen ser:

  • Prohibir cualquier ruta absoluta en los archivos del proyecto para cualquiera de los IDE.
  • Establezca los archivos del proyecto para emitir los archivos de clase al mismo directorio.
  • SVN: Ignore el directorio privado en el directorio .nbproject.
  • SVN: Ignore el directorio utilizado para la salida del archivo de clase de los IDE y cualquier otro director de ejecución generado como el directorio de registros anterior.
  • Haga que las personas usen ambos de manera consistente para que las diferencias se resuelvan rápidamente.
  • También mantenga un sistema de compilación independiente de los IDE, como Cruisecontrol.
  • Use UTF-8 y corrija cualquier problema de codificación de inmediato.

Estamos desarrollando en Fedora 9 de 32 y 64 bits, Vista y Windows XP y aproximadamente la mitad de los desarrolladores utilizan un IDE u otro.Algunos usan ambos y alternan con regularidad.

Probablemente lo mejor sea no confirme cualquier archivo relacionado con IDE (como el .project de Eclipse), de esa manera todos pueden verificar el proyecto y hacer lo que quieran.

Dicho esto, supongo que la mayoría de los IDE tienen su propio esquema de archivos de configuración, por lo que tal vez puedas confirmarlo todo sin tener ningún conflicto, pero en mi opinión se siente complicado.

En su mayor parte, estoy de acuerdo con Seldaek, pero también me inclino a decir que al menos deberías proporcionar un archivo que diga cuáles son las dependencias, qué versión de Java usar para compilar, etc., y cualquier cosa adicional que un NetBeans. Es posible que el desarrollador de /Eclipse necesite compilar en su IDE.

Actualmente solo usamos Eclipse, por lo que enviamos todos los archivos .classpath .project de Eclipse a svn, lo cual creo que es la mejor solución porque entonces todos también podrán reproducir errores y demás fácilmente en lugar de perder el tiempo con los detalles del IDE.

Soy de la filosofía de que la construcción debe realizarse con un enfoque de "mínimo común denominador".Lo que entra en el control de fuente es lo que se requiere para realizar la compilación.Si bien desarrollo exclusivamente con Eclipse, mi compilación es con ant en la línea de comando.

Con respecto al control de código fuente, solo reviso los archivos que son esenciales para la compilación desde la línea de comando.Sin archivos de Eclipse.Cuando configuro una nueva máquina de desarrollo (parece dos veces al año), se necesita un poco de esfuerzo para que Eclipse importe el proyecto desde un archivo de compilación ant, pero nada aterrador.(En teoría, esto debería funcionar igual para otros IDE, ¿no?¿Seguramente deben poder importar desde ant?)

También he documentado cómo configurar un entorno de construcción mínimo.

Utilizo maven y reviso solo el pom y la fuente.
Después de revisar un proyecto, ejecuto mvn eclipse:eclipse
Le digo a svn que ignore el .proyecto generado, etc.

Esto es lo que hago:

  1. Mantenga únicamente en el control de código fuente su script de compilación ant y su classpath asociada.Classpath podría ser explícito en el script ant, un archivo de propiedades o administrado por ivy.
  2. escriba un objetivo de hormiga para generar el archivo .classpath de Eclipse a partir del classpath de hormiga
  3. Netbeans usará su script de compilación y su classpath, simplemente configúrelo para hacerlo a través de un proyecto de formato libre.

De esta manera obtendrás scripts de compilación independientes de IDE y desarrolladores satisfechos :)

Hay un blog en el sitio de Netbeans sobre cómo hacer 3.pero no puedo encontrarlo ahora.He puesto algunas notas sobre cómo hacer lo anterior en mi sitio. Texto del enlace (aunque rápido y feo, lo siento)

Tenga en cuenta que si está utilizando Ivy (una buena idea) y eclipse, es posible que tenga la tentación de utilizar el complemento eclipse ivy.Lo usé y descubrí que tiene muchos errores y es poco confiable.Mejor usar 2.arriba.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top