Por que maven? Quais são os benefícios?

Quais são os principais benefícios de usar o maven em comparação com digamos formiga? Parece ser mais um aborrecimento do que uma ferramenta útil. Eu uso o maven 2, com o Eclipse Java EE simples (sem m2eclipse) e o tomcat.

Os defensores do maven acreditam que

  1. Maven permite que você obtenha suas dependencies de pacotes facilmente

  2. Maven força você a ter uma estrutura de diretórios padrão

Em minha experiência

  1. Descobrir dependencies de pacotes não é tão difícil assim. Você raramente faz isso de qualquer maneira. Provavelmente uma vez durante a configuração do projeto e mais alguns durante as atualizações. Com o maven, você acabará corrigindo dependencies incompatíveis, poms mal escritos e fazendo exclusões de pacotes de qualquer maneira.

  2. Lento ciclo FIX-COMPILE-DEPLOY-DEBUG, que mata a produtividade. Essa é a minha principal reclamação. Você faz uma mudança, você tem que esperar pela build maven para chutar e esperar que ela seja implementada. Nenhuma implantação quente qualquer.

Ou estou apenas fazendo errado? Por favor, aponte-me para a direção certa, eu sou todo ouvidos.

Descobrir dependencies de pacotes não é tão difícil assim. Você raramente faz isso de qualquer maneira. Provavelmente uma vez durante a configuração do projeto e mais alguns durante as atualizações. Com o maven, você acabará corrigindo dependencies incompatíveis, poms mal escritos e fazendo exclusões de pacotes de qualquer maneira.

Não é tão difícil … para projetos de brinquedos. Mas os projetos em que trabalho têm muitos, muitos, deles, e eu estou muito feliz em tê-los transitivamente, para ter um esquema de nomenclatura padronizado para eles. Gerenciar tudo isso manualmente à mão seria um pesadelo.

E sim, às vezes você tem que trabalhar na convergência de dependencies. Mas pense nisso duas vezes, isso não é inerente ao Maven, isso é inerente a qualquer sistema usando dependencies (e eu estou falando sobre dependencies Java em geral aqui).

Então, com Ant, você tem que fazer o mesmo trabalho, exceto que você tem que fazer tudo manualmente: pegando alguma versão do projeto A e suas dependencies, pegando alguma versão do projeto B e suas dependencies, descobrindo quais versões exatas eles usam, verificando que eles não se sobreponham, verificando se eles não são incompatíveis, etc. Bem-vindo ao inferno.

Por outro lado, o Maven suporta o gerenciamento de dependencies e as recuperará transitivamente para mim e fornece as ferramentas necessárias para gerenciar a complexidade inerente ao gerenciamento de dependencies : posso analisar uma tree de dependência, controlar as versões usadas em dependencies transitivas, excluir algumas das Se necessário, controle a convergência entre os módulos, etc. Não há mágica. Mas pelo menos você tem apoio.

E não se esqueça de que o gerenciamento de dependencies é apenas uma pequena parte do que o Maven oferece, há muito mais (nem mesmo mencionar as outras ferramentas que se integram muito bem ao Maven, por exemplo, o Sonar ).

Lento ciclo FIX-COMPILE-DEPLOY-DEBUG, que mata a produtividade. Essa é a minha principal reclamação. Você faz uma mudança, você tem que esperar pela build maven para chutar e esperar que ela seja implementada. Nenhuma implantação quente qualquer.

Primeiro, por que você usa o Maven assim? Eu não. Eu uso meu IDE para escrever testes, codificar até que eles passem, refatorar, implantar, implantar a quente e executar uma compilation Maven local quando terminar, antes de confirmar, para ter certeza de que não quebrarei a construção contínua.

Em segundo lugar, não tenho certeza se usar o Ant tornaria as coisas muito melhores. E, para minha experiência, as construções modulares do Maven usando dependencies binárias me dão um tempo de compilation mais rápido do que as construções típicas do Ant monolítico. De qualquer forma, dê uma olhada no Maven Shell para um ambiente pronto para (re) usar o Maven (o que é incrível por sinal).

Então, no final, e eu sinto muito em dizer isso, não é realmente Maven que está matando a sua produtividade, é você abusando de suas ferramentas. E se você não está feliz com isso, bem, o que posso dizer, não o use. Pessoalmente, estou usando o Maven desde 2003 e nunca olhei para trás.

O Maven pode ser considerado uma ferramenta de desenvolvimento de projeto completa e não apenas uma ferramenta como o Ant. Você deve usar o Eclipse IDE com o plugin maven para corrigir todos os seus problemas.

Aqui estão algumas vantagens do Maven, citadas na página Benefícios do uso do Maven :

Henning

  • configuração rápida do projeto, sem arquivos build.xml complicados, apenas um POM e ir
  • Todos os desenvolvedores em um projeto usam as mesmas dependencies jar devido ao POM centralizado.
  • obter vários relatórios e métricas para um projeto “de graça”
  • reduzir o tamanho das distribuições de fonts, porque os flasks podem ser extraídos de um local central

Emmanuel Venisse

  • muitos objectives estão disponíveis, por isso não é necessário desenvolver alguma parte específica do processo de construção contrária à ANT, podemos reutilizar as tarefas ANT existentes no processo de criação com o plugin antrun

Jesse Mcconnell

  • Promove design modular de código. ao simplificar o gerenciamento de vários projetos, ele permite que o projeto seja dividido em várias partes lógicas, unindo essas partes através do uso de rastreamento de dependência em arquivos pom.
  • Reforça o design modular de código. é fácil pagar o serviço labial ao código modular, mas quando o código está em projetos de compilation separados, é impossível cruzar as referências de polinização entre os módulos de código, a menos que você permita especificamente isso em seu gerenciamento de dependência … faça isso agora e corrija depois implementações.
  • Gerenciamento de dependência é claramente declarado. com o mecanismo de gerenciamento de dependencies você tem que tentar estragar seu versioning de jar … não há nenhum problema clássico de ‘qual versão deste jar de fornecedor é essa?’ E configurá-lo em um projeto existente rasga a parte superior da bagunça existente se ela existir quando você for forçado a fazer versões ‘desconhecidas’ em seu repository para colocar as coisas em funcionamento … ou mentir para si mesmo que você conhece versão atual do ABC.jar.
  • Um ciclo de vida forte e tipificado existe um ciclo de vida definido que um sistema de software percorre desde o início de uma construção até o final … e os usuários podem misturar e combinar seu sistema com o ciclo de vida em vez de montar seu próprio ciclo de vida. isso tem o benefício adicional de permitir que as pessoas passem de um projeto para outro e falem usando o mesmo vocabulário em termos de desenvolvimento de software.

Vincent Massol

  • Maior momento: a formiga é agora legada e não se move rapidamente à frente. O Maven está progredindo rapidamente e há o potencial de ter muitas ferramentas de alto valor em torno do Maven (CI, projeto do Dashboard, integração do IDE, etc.).

Descobrir dependencies para pequenos projetos não é difícil. Mas uma vez que você comece a lidar com uma tree de dependencies com centenas de dependencies, as coisas podem facilmente ficar fora de controle. (Eu estou falando da experiência aqui …)

O outro ponto é que se você usar um IDE com compilation incremental e suporte a Maven (como o Eclipse + m2eclipse), então você deve ser capaz de configurar a edição / compilation / implementação e teste a quente.

Eu pessoalmente não faço isso porque passei a desconfiar desse modo de desenvolvimento devido a más experiências no passado (pré Maven). Talvez alguém possa comentar se isso realmente funciona com o Eclipse + m2eclipse.

O Maven é uma das ferramentas onde você precisa decidir antecipadamente que você gosta e quer usá-lo, já que você gastará um bom tempo aprendendo, e ter tomado essa decisão de uma vez por todas permitirá que você pule todos os tipos. de dúvida enquanto aprende (porque você gosta e quer usá-lo)!

As convenções fortes ajudam em muitos lugares – como Hudson, que podem fazer maravilhas com projetos Maven -, mas pode ser difícil ver inicialmente.

edit: A partir de 2016, o Maven é a única ferramenta de compilation Java onde todos os três IDEs principais podem usar as fonts prontas para uso. Em outras palavras, o uso de maven torna sua build independente de IDE. Isso permite, por exemplo, usar o perfil do NetBeans, mesmo se você trabalha normalmente no eclipse

As vantagens de Maven sobre a formiga são muito poucas. Eu tento resumi-los aqui.

Convenção sobre Configuração
O Maven usa uma abordagem distinta para o layout e a boot do projeto, o que torna fácil simplesmente pular em um projeto. Geralmente, só é necessário o checkpoint e o comando maven para obter os artefatos do projeto.

Modularização de Projetos
As convenções do projeto sugerem (ou melhor, forçam) o desenvolvedor a modularizar o projeto. Em vez de um projeto monolítico, você é frequentemente forçado a dividir seu projeto em subcomponentes menores, o que facilita a debugging e o gerenciamento da estrutura geral do projeto.

Gerenciamento de dependência e ciclo de vida do projeto
No geral, com uma boa configuração de SCM e um repository interno, o gerenciamento de dependencies é bastante fácil, e você é novamente forçado a pensar em termos de versões de componentes do Project Lifecycle, gerenciamento de versões e assim por diante. Um pouco mais complexo que a formiga alguma coisa, mas novamente, uma melhoria na qualidade do projeto.

O que há de errado com o maven?
Maven não é fácil. O ciclo de construção (o que é feito e quando) não é tão claro dentro do POM. Além disso, alguns problemas surgem com a qualidade dos componentes e falta de dependencies em repositorys públicos.
A melhor abordagem (para mim) é ter um repository interno para armazenar em cache (e manter) as dependencies, e para aplicar no gerenciamento de release de componentes. Para projetos maiores que os exemplos de projetos em um livro, você irá agradecer ao maven antes ou depois

A Maven pode fornecer benefícios para o seu processo de construção, empregando práticas e convenções padrão para acelerar seu ciclo de desenvolvimento e, ao mesmo tempo, ajudá-lo a alcançar uma taxa de sucesso maior. Para uma visão mais detalhada de como a Maven pode ajudá-lo com o seu processo de desenvolvimento, consulte os Benefícios do Uso do Maven.

O Maven é uma poderosa ferramenta de gerenciamento de projetos baseada no POM (project object model). Ele é usado para criação, dependência e documentação de projetos. Simplifica o processo de construção como ANT. Mas é muito avançado do que ANT. Maven ajuda a gerenciar – Builds, Documentação, Reporter, SCMs, Releases, Distribuição. – maven repository é um diretório do arquivo JAR empacotado com o arquivo pom.xml. O Maven procura por dependencies nos repositorys.

Eu nunca encontrei o ponto 2? Você pode explicar por que acha que isso afeta a implantação de alguma forma? Se houver alguma coisa, o maven permite estruturar seus projetos de uma maneira modular que, na verdade, permite hot fixes para bugs em um determinado nível, e permite o desenvolvimento independente de uma API a partir do restante do projeto, por exemplo.

É possível que você esteja tentando empilhar tudo em um único módulo, caso em que o problema não é realmente muito comum, mas do jeito que você está usando.

Isso deveria ter sido um comentário, mas não foi adequado em um comentário, então eu postei isso como uma resposta.

Todos os benefícios mencionados em outras respostas são alcançados por meios mais simples do que usando maven. Se, por exemplo, você é novo em um projeto, de qualquer maneira você gastará mais tempo criando arquitetura de projeto, juntando componentes, codificando do que baixando jars e copiando-os para a pasta lib. Se você tem experiência em seu domínio, já sabe como iniciar o projeto com quais bibliotecas. Eu não vejo nenhum benefício em usar o maven, especialmente quando ele apresenta muitos problemas enquanto faz automaticamente o “gerenciamento de dependencies”.

Eu só tenho conhecimento de nível intermediário de maven, mas eu lhe digo, eu fiz grandes projetos (como ERPs) sem usar maven.