2010-08-22 10 views

Respuesta

2

Probablemente esta sea una mejor pregunta para stacoverflow.com, pero recomendaría Ant. Es muy robusto y flexible.

1

Ant y maven son herramientas de construcción demasiado grandes. Con maven, si quieres hacer compilaciones personalizadas, es probable que tengas que escribir tu propio plugin maven, que no es tan difícil. Hay una gran cantidad de documentación en línea para crear su propio complemento. Lo mejor de hacer un plugin maven es que es fácil compartirlo en una organización o con un equipo de desarrolladores; compartir estos complementos, por lo general, debe ser el anfitrión de su propio repositorio maven.

Ant es realmente bastante flexible ya que tiene un conjunto realmente extenso de etiquetas para hacer cualquier cosa, incluyendo construir, ejecutar pruebas, mover archivos, verificar el código de un repositorio e incluso ejecutar comandos en un servidor remoto. En mi opinión, es más fácil trabajar con hormiga cuando tienes que hacer compilaciones personalizadas. El problema con la hormiga es que es más difícil convertirla en un módulo compartible que puedes compartir y configurar como lo harías con un plugin maven.

Ivy es otra herramienta de construcción popular, sin embargo, no tengo experiencia con ella.

+0

Ivy no es una herramienta buld, es sólo una herramienta de gestión de la dependencia que juega muy bien con la hormiga (proporciona soporte nativo para ello). –

2

La mejor herramienta de construcción para Java Sé hasta ahora parece ser experta, pero todavía no da tanta flexibilidad como cmake en absoluto!

Eso podría ser cierto, pero le preguntaría si realmente necesita esa "flexibilidad". Parte del mayor valor de maven es que estandariza el desarrollo. La forma en que se administran los recursos/recursos, la dependencia, los ciclos de vida bien definidos, etc.

Es gracias a esta estandarización que puede conectar servidores de construcción, IDEs, herramientas de prueba automatizadas y muchas más herramientas fácilmente. También es importante que a los nuevos desarrolladores les resulte más fácil familiarizarse con la base de códigos porque saben qué estructura esperar.

Esos beneficios se perderían si tiene una versión "flexible", sin embargo, ¿realmente va a ganar algo con una construcción "flexible"? MUCHA gente está usando maven, y para casi todos los problemas ya crearon una solución. Si se esfuerza por utilizar esas soluciones estandarizadas, tendrá mucho menos problemas con la creación de mi humilde opinión.

En caso de que tenga la rara situación en la que realmente necesita hacer algo que no se puede hacer de forma estandarizada, puede enlazar scripts/tareas, etc. en maven e incluso escribir complementos personalizados. Pero realmente dudo que alguna vez necesites hacer eso.

-1

CMake no tiene ningún concepto de dependencias (solo en dependencias de fuentes para archivos objeto o bibliotecas compartidas) pero no en el nivel de artefactos (como jar en Java) o RPM etc. Llamaré a esto dependencias de módulos. CMake no tiene un concepto de dependencias transitivas, etc. CMake no tiene ningún concepto de estructura definida de un proyecto (Convención sobre la configuración). CMake no tiene ningún concepto de repositorio (como Maven tiene). CMake no tiene soporte de pruebas de unidad/integración integradas. Sin ciclo de vida de construcción definido. CMake no tiene ningún concepto de Release Management (que maven tiene), etc.

but it still doesn't give so much flexibility as cmake at all! 

¿Qué es exactamente lo que extrañas aquí en Maven?

+0

Es curioso cómo las personas pueden ver la misma realidad y ver cosas completamente opuestas. Desafiar "tener un concepto" de todas estas cosas es exactamente lo que lo hace menos flexible: no puede desviarse de los conceptos de Maven o agregar fácilmente otros nuevos. Mientras que CMake le permite hacer absolutamente cualquier cosa fácilmente, pero hacer que todo funcione en conjunto se vuelve progresivamente más difícil cuanto más compleja es la construcción. –

+1

La flexibilidad de la que está hablando hace que una compilación en el proyecto grande sea un desastre (cree un proyecto de desarrollo separado: la compilación), porque mientras más flexibilidad tenga, más tendrá que mantener. Maven tiene suficiente flexibilidad para hacer su trabajo. Puede haber situaciones en las que alcance un límite, pero luego simplemente puede crear un complemento. ¿Estás diciendo que puedes hacer absolutamente todo con facilidad? Hm ... Eso significa que, por otro lado, tienes que definir estos o conceptos similares primero en un proyecto y eso lleva mucho tiempo. – khmarbaise

+0

@khmarbaise: la falta de flexibilidad hace que construir un gran proyecto sea un desastre porque no hay forma de que los autores de Maven puedan satisfacer cada proyecto (de hecho, Maven solo es bueno para pequeños proyectos de juguete). Los complementos personalizados son una forma difícil de lograr objetivos simples que puedes hacer con simples scripts de shell. Y dependencias ... bueno, hay algunos buenos ejemplos de la historia como los administradores de paquetes de Linux. Sin embargo, los desarrolladores de juguetes de Maven lo arruinaron por completo de la peor manera posible. Llamarlo "administrador de dependencias" es insultar a los administradores de paquetes REALES. Y la gestión de lanzamientos es una buena palabra de moda. Puedo escribir guiones en pocas líneas. – woky

Cuestiones relacionadas