Buildr, Gradle ou esperar por Maven 3? [fechadas]

Question

Estou realmente cansado de lutar com Maven 2 o tempo todo. ferramentas de compilação não deve ser no caminho. Recentemente tenho estado a olhar para Buildr e Gradle. Maven 3 parece corrigir algumas das lutas. Então, o que eu deveria ir para agora? Buildr? Gradle? Ou esperar um ano para Maven 3?

Answer 1

No sistema de construção é uma bala mágica. Acho Maven resolve mais problemas do que faz para mim, mas estou bastante confortável plugins de escrita para contornar suas deficiências, eu também lidar com centenas de projetos, de modo processamento de herança e dependência do Maven é bastante útil para mim.

Procure SO um pouco e você verá Buildr e Gradle ambos têm questões muito (mesmo para Ant e Ivy), geralmente você está trocando um conjunto de problemas para outro e seu um caso de encontrar o menos doloroso.

Existe alguma coisa em particular que está incomodando você sobre Maven ou é uma coceira geral? Se é um problema particular que vale a pena olhar para as Maven 3 questões sobre Jira , se o problema não é abordada, você pode aumentá-lo, ou então pode haver pouco ponto em que você espera

Answer 2

Eu não esperaria muito de Maven 3. As pessoas por trás do pedigree Maven de ferramentas de compilação sempre tive a hipótese de que projeto cria são homogêneos, ou seja: todos os problemas de construção, fundamentalmente, resumem-se ao mesmo problema. Esta visão do mundo pode ser mantido bastante consistente em face de pontos de vista opostos, mas tem um custo. A ausência de lógica de script em Maven ( "quando você quer script que você sabe que está fazendo algo errado"), a API complicado plug-in ( "nenhum usuário Maven ordinária deve querer escrever um plugin") eo repositório central ( "nós todos têm as mesmas dependências ") são todos os testamentos de esta hipótese abrangente.

No mundo real, problemas de compilação são heterogêneos, porque as pessoas constroem software para uma ampla variedade de razões. Todos eles 'desenvolver' como nós todos 'furos' de vez em quando para resolver problemas específicos. Independentemente do seu nível de abstração que você sempre vai encontrar semelhanças quando se comparam os problemas de construção arbitrárias. É o reveration dessas semelhanças e a condenação de diferenças que é a queda para o projeto do Maven ea razão pela qual ele desenha muito à prova de balas. Basicamente, Maven é autoritário e utópica em sua perspectiva.

PS:. Maven tem boas características, como a Convenção-over-configuração e a idéia de usar repositórios (a implementação Maven desta idéia é problemático)

Answer 3

Nós usamos Maven aqui, mas acho que uma vez que você começa fora de um projeto simples, o pom.xml começa a ficar mais e mais complexa. Você começa a gastar muito tempo trabalhando fora como o diabo para configurar o seu pom para fazer o que quiser, e como resolver as diversas questões.

A única coisa que realmente me pegou foi a orelha que estamos construindo. Temos múltiplas guerras no arquivo ouvido, e Maven normalmente adere as bibliotecas nas guerras. No entanto, para reduzir o tamanho das guerras, e para manter os frascos tudo a mesma coisa, queríamos colocar os frascos compartilhados entre as guerras no diretório lib da orelha.

Infelizmente, Maven não lidar com isso muito bem. Precisávamos configurar manualmente este para cada um dos poms das guerras, e em seguida, adicionar todas estas dependências em pom da orelha.

Em outro projeto, temos arquivos de ajuda baseado em HTML. As pessoas que escrevem a escrita ajuda-los em Microsoft Word, em seguida, usar um programa para traduzi-los em HTML. A mudança de caráter único pode reverberar por centenas de arquivos.

Para contornar este problema, o nosso sistema de ajuda é armazenado em nosso repositório fonte como um único arquivo compactado. Quando a nossa equipe de documentação cria um novo conjunto de arquivos de ajuda, eles zip-lo e substituir o que está no repositório.

Assim, parte da minha compilação é descompactar o arquivo e colocá-lo na guerra. Fácil de fazer em Formiga, não pode fazê-lo em Maven menos que você use o plugin antrun que lhe permite escrever código Ant a questões punho que Maven não pode manipular sem um plugin desenvolvido.

Eu posso ver o que Maven está fazendo, mas a teoria ficou à frente da realidade. O que eu achei é que Ivy e Ant pode fazer a maior parte da verificação de dependência que Maven faz sem todas as questões de escrever e manter os poms.

Se você não estiver usando Maven, Ant tentar com Ivy primeiro. Então, quando, Maven 3 sai, tente isso. Lembro-me da transição do Maven 1 a Maven 2. Eles eram totalmente incompatíveis entre si e qualquer coisa que você aprendeu usando Maven 1 era obsoleto. Seria tolo para aprender e refazer seus projetos em Maven 2, de repente, encontrar-se refazer tudo para Maven 3.

Answer 4

maven 3.x já está incorporado em IDEs (pelo menos no netbeans, verificação este link para obter mais obter informação). Você pode jogar hoje com 3.x maven simplesmente construir um projeto Maven com NetBeans.

Outra notícia boa é que o perito tem mais apoio 'empresa' com a integração de EJB / WS em projectos de IDE (mais uma vez, pelo menos no netbeans).

Assim, gostaria de ficar com 2.x maven para a produção constrói e jogo com 3.x maven para o desenvolvimento.

Answer 5

Maven 2 e 3 têm ambos trabalhado perfeitamente para mim em uma variedade de projetos. Atualmente, estou usando Maven 3 alfa 7, que funciona muito bem, especialmente em conjunto com o plugin Eclipse Maven.

Maven integra perfeitamente com Ant - em ambos os sentidos. No meu projeto atual, nós invocamos Maven de Ant várias vezes, a fim de realizar o teste de integração complexa. Da mesma forma, usamos Ant via antrun plug-in do Maven, e nós também escreveu nossos próprios plugins Maven. Este, aliás, é uma questão de minutos e resume-se a escrever um Pojo anotada.

Maven recebe muitas críticas porque muitos desenvolvedores não gostam de regras ou convenções. Muito simplesmente, ninguém o obriga a usar Maven. Se você quer liberdade total - por qualquer meio - re-escrever o seu próprio processo de construção para cada projeto que você participar. No entanto, se você gosta de criar software em vez de re-inventar a roda com um processo de construção feito por encomenda em cada projeto, ir para Maven.

Answer 6

Mantenha o seu código bem conservado e dividido em módulos bem definidos e portar entre sistemas de construção torna-se um problema menor.

Por enquanto, o Maven-2 é uma boa escolha para o meio 2/3 dos projetos. Para o muito simples, formiga ainda é ok. Para o muito complexo, um híbrido de maven-2 e outras ferramentas (como antrun) torna-se inevitável.

Não sei por que você está tendo problemas com maven-2.

Ela difere da formiga e Buildr na medida em que é uma ferramenta para descrever seu processo de criação, não scripts-lo. Complexo constrói, aqueles com múltiplas partes dinâmicas e dependências aninhadas e / ou transitórios são difíceis de construir, porque eles são difíceis de descrever.

Answer 7

Dê Malha https://github.com/hackingspirit/Lattice uma tentativa. Eu sou o autor. Aqui está a colher:

arquivos de compilação em látice não são escritos em XML, mas na linguagem Python. Os fícios Ben estão muito melhor legibilidade e poderosa scripting construção imperativo apoiado por Python. Para projetos multi-módulo. usos de rede topológica triagem para decidir a ordem correta para construir cada módulo. Também está previsto que Malha vai analisar a dependência do módulo para determinar como a compilação do módulo pode ser paralelizado. código-fonte de rede é extremamente magra, atualmente consiste de cerca de 500 linhas de código Python.

Answer 8

Eu acho que as pessoas reclamando sobre Maven deve gastar um pouco de tempo extra investigando plugins disponíveis. Em resposta aos comentários reclamando que Maven é rígida e dificulta a construção lógica uso custom / fornecer controle de grão fino sobre o processo de construção - Eu recomendaria olhando para Ant plug-in para o Maven (na verdade existem vários, mas aqui é um : http://maven.apache.org/plugins/maven-antrun-plugin). Eu tenho tido grande sucesso personalização Maven constrói com ele ao longo dos anos. Basicamente, ele permite que você execute qualquer comando Ant como parte da compilação Maven, e você pode fazer praticamente qualquer coisa com Ant;)

Answer 9

Ant com Ivy faz o mesmo gerenciamento de dependência Maven faz (na verdade, ele usa infra-estrutura de gerenciamento de dependência inteira do Maven incluindo os mesmos repositórios de URL), mas sem toda a confusão configuração POM.

Ant com Ivy pode ser uma maneira de lidar com os problemas de dependência para as pessoas que realmente não querem usar Maven. Ele resolve 90% das coisas que Maven era suposto resolver.