Practica para asegurar que los proyectos de Android se construyan justo después de la salida de SVN en Eclipse

Problema:

Cuando un proyecto se registra en SVN y alguien más lo revisa, aparece un signo de exclamación y los errores de ruta de compilation deben resolverse. ¿Como arreglarlo?

Como ejemplo, tengo un proyecto y lo siguiente es su estructura:

Tiene 3 bibliotecas en la carpeta libs:

* android-support-v4.jar * bugsense3.2.2.jar * gcm.jar 

La carpeta Dependencias de Android tiene:

 * annotations.jar 

Bibliotecas referencedas tiene:

 * gcm.jar 

Las bibliotecas privadas de Android tienen:

 * bugsense3.2.2.jar * gcm.jar * android-support-v4.jar 

Google APIs [Android 2.2] tiene:

 * android.jar * maps.jar 

Entonces, parece que todo lo que colocamos en la carpeta libs se agrega automáticamente a las bibliotecas privadas de Android, ¿es eso exacto? Para que puedan registrarse en SVN y cuando alguien más lo revise y lo cree, los .jars en las bibliotecas privadas de Android simplemente señalarán su espacio de trabajo local, así que eso no es un problema.

Sin embargo, annotations.jar en Android Dependencies y android.jar y maps.jar en Google API hacen reference a la carpeta android-sdk en mi C :. Entonces, cuando alguien más revisa todo mi proyecto, tienen problemas de compilation que deben resolver a través de Java Build Path.

¿Cuál es la práctica estándar de tener todas las bibliotecas almacenadas en SVN de forma tal que cuando un nuevo desarrollador ingresa y verifica el proyecto, simplemente construya sin alterar la configuration? Sospecho que vamos a utilizar un sistema de administración de compilation, continuous integration, server de compilation, etc., etc. Así que sé un poco, pero nunca lo he usado en la práctica ya que nunca he trabajado en un equipo lo suficientemente grande. . Si alguien fuera tan amable de darme exactamente lo que usa (las herramientas reales como Maven, Gradle, etc.), ¡sería muy apreciado!

Gracias,

-V

No hay nada especial acerca de las bibliotecas que el ADK agrega a la ruta de class. Si desea poder verificar todas las dependencies de su proyecto, puede copyr las jarras referencedas en un directory local y luego señalar la ruta de class a esas en lugar de usar los grupos de bibliotecas proporcionados. Debido a que el plugin de Android tiene ese nuevo sistema loco que agrega automáticamente cosas en el directory libs a su ruta y a su apk, no recomendaría poner estos otros flasks ahí. Normalmente lo que haremos aquí es crear una carpeta separada en svn llamada third-party o algo así, y luego usar svn: externals para hacer reference a los jar necesarios. Tener un lugar común para almacenar files jar de terceros facilita la gestión de versiones y configuration.

Para ilustrar las cosas un poco más claramente, esto es lo que sería un ejemplo de un repository de subversión:

 repo -android_project -trunk -your other project stuff (src, etc) -libs -android-support-v4.jar -bugsense3.2.2.jar -gcm.jar -third-party -annotations.jar (external) -android.jar (external) -maps.jar (external) third-party -android -v_X.XX -annotations.jar -android.jar -maps.jar 

En su proyecto Eclipse real, debe agregar las cosas en un tercero a la ruta de forma manual, y el adk agregará las cosas en libs a la ruta de forma automática.

EDITAR

Sobre el tema de este método contra Maven, lo primero que admitiré es que no tengo una gran cantidad de experiencia con Maven. Por lo que sé al respecto, no creo que cumpla con sus criterios. Cuando utilicé Maven, de forma pnetworkingeterminada descargaba sus dependencies a una location específica de la máquina, en lugar de a su área de trabajo. Para que Eclipse recoja estas dependencies, luego debe agregar una propiedad M2_HOME a su espacio de trabajo para que pueda resolver todas las routes correctamente. Fue muy fácil configurar todo esto porque había mvn commands para automatizar el process, pero para alguien que no esté familiarizado con el sistema podría causar mucha confusión y ralentizar las cosas cuando un nuevo desarrollador está comenzando un proyecto. Además, un gran problema que encontramos es que requiere que las dependencies se almacenen en algún tipo de repository central, lo que hace que trabajar en áreas no conectadas sea muy difícil.

Una vez más, no soy un experto en Maven, así que tomo lo que he dicho con un grano de sal, pero por mi experiencia Maven funciona muy bien en un entorno de código abierto donde la conectividad es bienvenida y casi garantizada, pero no tanto en una fuente cerrada ambiente. Parecía que causaba más problemas de los que solucionó para nosotros y, por lo tanto, nunca se entendieron. Lo bueno del sistema que describí arriba es que después de pagar, usted tiene una sola carpeta que contiene todo (excepto eclipse) que se requiere para desarrollar y build el proyecto. Eso hace que las cosas sean muy fáciles de poner en funcionamiento en una máquina nueva o en un entorno desconocido.

Diré que un gran beneficio proporcionado por Maven es la consistencia. Con el sistema que describí, el desarrollador está a cargo de cada aspecto de la configuration de un proyecto. Esto significa que entre desarrolladores y proyectos puede get variaciones en cómo se distribuye su repository svn. Un desarrollador podría nombrar un directory "de terceros" mientras que otro podría llamarlo "de código abierto", o algunos desarrolladores podrían no usar un enlace troncal en sus proyectos. Con el time, estas pequeñas cosas pueden acumularse y dejar su depósito en un lío. Como Maven está a cargo del layout del proyecto, puede estar seguro de que su repository se mantendrá constante.