¿Cómo crear un PPA para un proyecto Maven?

Quería intentar crear mi propio PPA. El proyecto que tengo es un proyecto de Java construido con Maven. Esto es lo que ya he hecho hasta ahora:

Creó un PPA.
Configure un nuevo proyecto en Launchpad.
Se agregó una rama que está importando mi proyecto desde un repositorio SVN.
Creé una receta para esa rama que publica las compilaciones en mi PPA.

Aquí es donde estoy atrapado.

He leído los tutoriales y busqué mucho en Google; pero no pude descubrir cómo construir mi proyecto.

Puedo comenzar una compilación para la rama; pero, como esperaba, falla. Supongo que tengo que poner información meta como un archivo MAKE en el repositorio. ¿Es posible incluso construir y empaquetar proyectos Maven en Launchpad? También intenté construir un archivo .deb localmente usando bzr dh-makey debuild. bzr dh-makecreó muchos archivos en la ./debiancarpeta pero debuildfalló. Supongo que funcionaría si especificara la metainformación correcta en mi proyecto, por lo que es el mismo problema que en Launchpad.

Sé que esta es una pregunta bastante general, pero creo que faltan tutoriales adecuados para empaquetar .debarchivos, incluso si no tiene un caso "exótico" como yo.

Para resumirlo:

¿Qué archivos / información debo proporcionar en mi proyecto para que pueda compilarse y empaquetarse correctamente?

Cualquier ayuda sería genial :-)

— André Stannek
fuente

un hecho es posible. Estoy buscando una solución, pero llevará algún tiempo

— RobotHumans

¿¿¿Entonces??? Como se hace Esto me está volviendo loco.

— i30817

@ i30817 - lo siento, estaba lejos por defcon, ahora estoy trabajando en un juego para ubuntu. completaré la respuesta tan rápido como lo permitan otras demandas

— RobotHumans

Estoy en el punto donde estoy tratando de llamar a debuild para ver si es capaz de construir el deb antes de cargarlo en un ppa. No hubo suerte: dh construcción --con javahelper dh_testdir dh_auto_configure jh_linkjars dh_auto_build jh_build dh_auto_test fakeroot debian / rules binary dh binaria --con javahelper dh_testroot dh_prep dh_installdirs dh_auto_install dh_install cp: no se puede stat ' `debian / tmp / bookjar.jar: No existe el fichero o directorio dh_install: cp -a debian / tmp / bookjar.jar debian / bookjar / usr / share / bookjar / código de salida devuelto 1 make: *** [binario] Error 2

— i30817

@ aking1012 sin prisa. Tampoco tengo tiempo para ese proyecto en este momento.

— André Stannek

Mira en mi proyecto bookjar: http://code.google.com/p/bookjar/source/browse/

específicamente el directorio debian (especialmente el archivo debian / package.sh) y el archivo build.xml (ant). En ese archivo hay una nueva 'carga' de destino que carga un artefacto construible en el robot de lanzamiento de la plataforma de lanzamiento.

Estoy usando hiedra y la infraestructura de hormigas netbeans, por lo que es probable que sea un poco diferente para usted. Sin embargo, una cosa es segura: no puede usar hiedra o maven desde el servidor de compilación remoto. Debe cargar todas las bibliotecas que usa, ya sea en forma de código o frascos. ivy: recupera las descargas de los archivos a current_dir / lib para que mi proyecto en netbeans esté configurado para buscar sus bibliotecas allí (nblibraries.properties es parte de la infraestructura de netbeans para eso). Lea el build.xml para obtener más detalles (básicamente, los archivos debian / rules llaman a un objetivo ant especial para construir en el servidor que no intenta vincular los archivos jar, porque ya están copiados allí).

También estoy aprovechando en mi package.sh que mi proyecto está en mercurial para construir un archivo de registro de cambios desde el registro hg, por lo que hay otros problemas que resolver si desea el mismo grado de automatismo y no usa hg (en de hecho, creo que mi registro de cambios está doblando las reglas de los registros de cambios de Debian al hacer que cada cambio sea una versión 'menor').

— i30817
fuente

Suena prometedor, pero pueden pasar algunos días antes de que tenga tiempo de investigarlo.

— André Stannek

Olvidado: en este esquema, usted es responsable de las cargas a las versiones de ppa en lugar de vincular la ppa a un repositorio de código con un archivo de vigilancia y hacer que se construya periódicamente. Lo prefiero de esta manera y ni siquiera intenté hacer lo otro, pero probablemente sea posible. Mi ppa se construyó con esto (¡ después de 13 intentos fallidos! ). También tenga cuidado porque su registro de cambios debe estar en un orden impecable para ser aceptado por debuild, lo que significa que su registro de hg también debe ser así, tuve que reiniciar el repositorio debido a un 'usuario' que no siguió el directrices

— i30817

Después de tres meses, es mucho mejor que nada ;-)

— André Stannek

Probablemente no desee utilizar el truco hg log> changelog. Tiene algunos requisitos dudosos, como no tener ninguna etiqueta hg, excepto las numéricas (lanzamientos) o tener que hacer que todos los comisionados de confirmación sigan las pautas de Debian (y dado que hg no permite cambiar el historial ... si esto sucede, use una extensión complicada o reiniciar el repositorio ... y en cualquier caso manguera clones remotos). Sin embargo, tiene la ventaja de no tener que mantener el registro de cambios si lo administra.

— i30817

Todavía no pude encontrar el tiempo para investigarlo :-( Solo quería que supieras que no he olvidado este problema.

— André Stannek