Admita, todos nós trabalhamos em builds no Maven por longas noites e noites, e naquele momento eu realmente queria contar a alguns criadores afetuosos dessa tecnologia maravilhosa. Às vezes os sonhos se tornam realidade! Zhenya e eu (
phillennium )
encontramos quase o principal desenvolvedor do Maven - Robert Scholte. E o que perguntamos a ele sobre ...
Leia mais →
Com o novo ciclo de lançamento, as versões Java saem uma após a outra, a décima primeira já apareceu, enquanto muitas estão sentadas na oitava. Em breve, você fará uma apresentação sobre como o Maven apoia tudo isso e não deseja estragar o relatório, mas faça uma pergunta nessa direção. O que você acha pessoalmente desse novo ciclo de lançamento que adiciona trabalho a você? Isso é uma mudança para melhor ou para pior?
Se você está falando de um ciclo de lançamento de 6 meses, o Maven é um pouco rápido. Nossa equipe é pequena o suficiente, temos cerca de 5 a 10 participantes ativos e todos são voluntários, nenhuma empresa está desenvolvendo o Maven. Portanto, todos devem trabalhar no projeto em seu tempo livre. Mudanças no Java criam muito trabalho. Sempre que uma nova versão é lançada, precisamos fornecer seu suporte, o que significa que não temos tempo para o Maven, plugins para ele ou qualquer outra coisa. Seria melhor para mim se o ciclo durasse um ano ou meio.
Outras pessoas que desenvolvem projetos para o ecossistema Java têm um sentimento semelhante, que também precisa fornecer suporte para as versões mais recentes?
A julgar pelo twitter, sim, a maioria concorda que 6 meses é muito rápido.
Você poderia contar a história de Maven? Se bem me lembro, ele foi criado há muito tempo para tornar a turbina Apache menos assustadora e dolorosa. Aliás, eu usei a Apache Turbine. Você se lembra dessa vez?
A história de Maven começou há muito tempo. Entrei no projeto há cerca de 8 anos, ou seja, durante a versão 3.0.3 ou 3.0.4. E neste momento, Maven já existe há algum tempo. Até onde eu sei, ele fazia parte do projeto Turbine. Uma ferramenta separada foi feita a partir de parte deste projeto, que se tornou o Maven. Eu, como provavelmente tudo, usei o Ant então. Eu não gostei disso toda vez que comecei a trabalhar em um novo projeto, precisava copiar todos esses arquivos Ant. Eu sabia que deveria haver uma solução melhor, comecei a procurá-lo na Internet e encontrei o Maven. No entanto, antes de entender a idéia principal do Maven, muito tempo se passou. No entanto, quando você entende, torna-se conveniente. Todos os problemas que tive com o Ant desapareceram. O Ant ainda é uma ótima ferramenta, mas se você estiver trabalhando em um projeto que combina muitas fontes, recomendo fortemente o Maven ou uma ferramenta similar.
Maven é apenas sobre Java. Eu tentei usá-lo para C ++, mas não foi muito bom. Existe um momento em que o Java não será mais e o que faremos então?
Das linguagens orientadas a objetos populares existentes, Java parece ser uma das mais antigas, já tem mais de 20 anos. Não olhei para as estatísticas mais recentes, mas tenho certeza de que o Java ainda é muito difundido. Eu acho que vai existir por algum tempo. Pelo menos espero que sim - significa que não ficarei sem trabalho.
Maven vai viver por muito tempo?
Mas esta é uma pergunta difícil. Até hoje, 65-80% dos projetos Java usam o Maven. Mesmo para um produto com mais de 15 anos, isso é muito. Provavelmente, muito mais pode ser melhorado no Maven. Temos ideias para o Maven 4 e até o Maven 5. Mas levará muito tempo para implementá-las. Penso que a ideia geral do Maven não se tornará obsoleta, mas outros sistemas de montagem podem superá-la. Como extraem experiência dos erros que cometemos no Maven e das decisões que tomamos corretamente, e com base nessa experiência, eles podem começar do zero. Uma das vantagens do Maven é a compatibilidade com versões anteriores. Mesmo um projeto escrito há 10 ou 15 anos pode ser montado usando a versão mais recente do Maven. Mas por causa disso, temos muitos códigos antigos no Maven Core. Deve ser substituído, mas isso não é tão fácil.
Tanto quanto me lembro, agora você ainda pode criar moji sem anotações.
Sim, é possível.
Antes da entrevista, tentei encontrar um tutorial sobre isso e não encontrei nada. É como se os langoliers estivessem nos perseguindo e corroendo todos os documentos antigos da Internet. Mas lembro que uma vez não havia anotações e convenções especiais eram usadas. Bem, vamos passar para outra pergunta. Você acha que o Maven tem uma concorrência real? Diga Gradle?
Gradle é um concorrente muito forte e já existe há algum tempo. Acredito que ter concorrência é bom, porque nos mantém em forma e nos permite ver algumas soluções alternativas. Eles apenas têm uma abordagem diferente de como coletar projetos, não há nada de errado nisso. Todos devem escolher o que melhor se adequa ao seu projeto. Talvez eu deva mencionar pro aqui . Esta é uma ferramenta escrita por Remi Forax da equipe ASM (analisador de bytecode). Ele, como eu, era membro do grupo de especialistas do projeto Jigsaw. Ele queria escrever uma ferramenta de construção que melhor refletisse as idéias Java. Ao criar um profissional, ele emprestou os melhores aspectos do Maven. Observar isso foi interessante. Foi uma demonstração projetada para mostrar que você pode usar os módulos Java 9 e benefícios relacionados no construtor.
Você disse que participou do projeto Jigsaw - e disse isso no passado. Ele deixou de existir? Ele ainda tem a oportunidade de se desenvolver?
Este JSR está fechado. É verdade que alguns problemas não resolvidos permaneceram, mas agora são tratados pela equipe de suporte.
O que causou mais dificuldades no desenvolvimento do Maven? Quais foram os problemas mais sérios? Não em termos de Java 9, mas em geral, com base em toda a experiência em desenvolvimento. Você pode escolher, digamos, os dois problemas mais importantes?
A questão não é fácil, mas vamos tentar. A parte na qual a resolução de dependência ocorre é extremamente complexa. Ainda estamos tentando melhorá-lo. Você deve ter notado que não havia a versão do Maven 3.4, após a versão 3.3.9 havia a 3.5.0 imediatamente. A principal razão para isso é que houve alterações significativas na resolução de dependências. Eles foram marcados como correções de bugs, mas percebemos que um número significativo de projetos foi quebrado de repente - eles dependiam dessas mudanças estranhas. Isso foi inaceitável. Portanto, fizemos o que não teríamos tomado em nenhuma outra circunstância - um repositório git com reinicialização rígida e, no Maven 3.5.0, começamos a selecionar apenas melhorias externas. Bem, e, é claro, fizemos o console multicolorido - todos gostaram.
Ok, agora é a segunda dificuldade!
Não foi fácil encontrar uma conexão com a comunidade Maven e ensiná-los a usar a ferramenta corretamente.
Para que todos saibam usar o Maven: copie algumas passagens de XML dos comentários no Stack Overflow e ele funciona. Não é?
Bem, bem. Não. Estou certo de que na maioria das vezes você será aconselhado a fazer uma instalação limpa, e isso não é verdade. Portanto, provavelmente, isso deve ser feito no Maven 2. Agora você precisa executar o mvn Verifique. Porque quando você limpa, tudo é excluído, todo o resultado do trabalho. E se os arquivos forem copiados de você - essas são operações de E / S, elas são lentas. Em geral, muitas coisas serão feitas várias vezes. A maioria dos plugins sabe quando eles precisam fazer seu trabalho. Como regra, não há necessidade de limpeza. Quanto à instalação, este comando copia apenas seus arquivos JAR para o repositório local. Isso, novamente, é uma operação de E / S desnecessária. Além disso, seu repositório local pode ficar sujo - ou seja, pode parecer diferente do repositório local do seu colega. Às vezes, isso pode levar a resultados interessantes. Então você deve executar o mvn Verifique, isso é o suficiente.
A propósito, eu acabei de abrir o maven.apache.org e diz: “O Apache Maven é uma ferramenta de gerenciamento e compreensão de projetos de software”. Mas muitas pessoas pensam que o Maven é apenas mais uma ferramenta de construção. Qual é a diferença entre uma ferramenta de montagem e uma ferramenta de gerenciamento de projetos?
Provavelmente é melhor não responder a essa pergunta - não fui eu quem a escreveu no site. Eu acho que o autor queria dizer que o Maven é muito mais do que apenas construir um projeto. Ele também está envolvido na resolução de dependências, fornece um formato de configuração, permite não instalar muitas coisas. Em geral, esta é uma enorme coleção de tudo no mundo.
Quais são os principais princípios e crenças da equipe Maven? Por exemplo, eles acham que uma abordagem declarativa é melhor que um imperativo? Algo como o Zen em Python. Você tem um conjunto de regras semelhante?
Eu acho que não. Em nossa opinião, a configuração dos plugins deve ser feita da maneira mais simples possível. Se existirem padrões razoáveis, eles deverão ser indicados. Isso facilitará a vida do usuário final. Pela primeira vez em muitos anos, alteramos recentemente a opção padrão para as versões de origem e destino - antes era 1.5, agora é 1.6. Queríamos que a opção padrão estivesse presente, porque sem ela a versão usada no JDK é usada. Nesse caso, se eu usar o Java 10 e outra pessoa usar o Java 12, teremos resultados diferentes. Você sempre deve especificar a origem e o destino. Mas se você começou a usar o Java 9, não é mais possível criar o Hello World com um arquivo pom simples e uma classe, pois o Java 9 requer pelo menos o Java 6 para os valores de origem e de destino. Portanto, decidimos fazer a versão padrão 1.6 e adicionamos um aviso de que se você ainda não especificou uma versão, isso deve ser feito - as pessoas devem saber que você precisa definir as versões de origem e de destino ou o valor do release se estiver trabalhando com o Java 9. Ou ambos.
Que dificuldades você vê para o Maven no futuro? Você disse que tenta não mudar o Maven com muita frequência. E, no entanto, o que nos espera no futuro?
Uma das mudanças mais significativas que queremos fazer diz respeito ao arquivo pom. Descobrimos que em algumas seções - especialmente no build - seria bom adicionar alguns elementos adicionais. Mas, por enquanto, não podemos fazer isso. O mesmo arquivo pom que você usa no seu sistema é carregado. Se você adicionar outros elementos a ele, eles violarão o XSD e outras ferramentas não poderão usá-lo.
Mas você pode alterar o XSD no cabeçalho?
Sim Mas não acho que toda ferramenta verifique o XSD. Eles apenas pensam que estão lidando com a versão 4.0.0. Portanto, fazer alterações será muito difícil. Decidimos dividir o arquivo pom em várias partes e começar com o Build POM. E o que será descarregado será chamado Consumer POM. Ele será gerado com base no Build POM e nenhuma ação adicional será necessária. E será totalmente compatível com o Maven POM 4.0.0. Ao dividir o POM em duas partes, podemos finalmente melhorá-lo significativamente e facilitar o uso do Maven. Essa é uma mudança no núcleo do Maven, e estamos trabalhando nisso há mais de um ano, incluindo a implementação no IDE. Isto não é fácil.
Alguns IDEs tentam incluir partes do Maven no IDE por motivos de integração, preenchimento automático, compilação incremental e assim por diante. Como fazer isso certo? Tanto quanto me lembro, algumas partes do Maven foram construídas no Eclipse há muito tempo.
Eu acho que essas tentativas são justificadas - esse sistema foi muito conveniente para os usuários devido à integração. Isso foi possível graças a uma das alterações significativas implementadas no Maven 3. Nela, a arquitetura foi refeita para fornecer melhor suporte no IDE. Os autores dessas mudanças trabalharam em estreita colaboração com o Eclipse, e essa solução veio daqui. Eu acho que isso é permitido. Eu sei que o NetBeans e o InelliJ têm uma abordagem completamente diferente, eles apenas chamam o Maven na linha de comando sem nenhuma integração.
Outro tópico importante é a velocidade do Maven. De alguma forma, podemos aumentá-lo? A resolução de dependência e as operações de E / S são muito lentas. Ainda hoje em um SSD.
Sim, algo pode ser feito. Primeiro, você precisa ver quantos kernels existem no seu sistema e iniciar o Maven com vários threads. Esta é uma das soluções. Além disso, dê uma olhada no Takari. Esta é uma empresa criada por Jason van Zayl, um dos fundadores da Maven. Ele escreveu algumas extensões interessantes e melhorou significativamente o suporte para montagens paralelas, ou seja, quando você cria vários projetos. Espero que um dia ele dê esses desenvolvimentos a Maven, mas por enquanto você deve dar uma olhada na página dele.
Você disse que estava trabalhando no Maven no seu tempo livre, certo? O fato de você ser um dos criadores do Maven ajuda em seu trabalho atual? Ou é apenas um hobby?
Eu trabalho como arquiteto de software em uma organização governamental na Holanda. É assim que eu ganho a vida. É claro que eles sabem que eu também trabalho no Maven, e periodicamente me fazem perguntas sobre o Maven. Mas no geral, sou apenas o arquiteto deles. E à noite, trabalho no Maven, tento melhorar, ajudar as pessoas.
Você trabalha em outros projetos de código aberto além do Maven?
Eu participo de outros dois projetos. Um deles é chamado MojoHaus, que desenvolveu uma parte significativa dos plugins do Maven. É verdade que agora faço pouco neste projeto, mas às vezes olho para lá e domino várias coisinhas. Outro projeto é chamado QDox. Analisa o código fonte. Também está associado ao Maven, pois é usado em alguns plugins. Essa experiência me ajuda, porque, por exemplo, no caso do descritor de módulo, introduzido no Java 9, a experiência me permitiu usar um descritor em plugins para o Maven.
A propósito, qual é sua opinião sobre Java 9, 10, 11? Devo usá-los ou é melhor ficar com o Java 8?
Migrar para versões mais recentes. Mesmo se você não estiver usando todos os recursos, atualize para o Java 10 ou aguarde algumas semanas e atualize para o Java 11. Basta usar o caminho de classe. Java é significativamente mais rápido graças à sua modularidade, mas o caminho da classe simplesmente funciona. Eu sei que muitos ainda pensam que você precisa adicionar um descritor de módulo ou usar um sistema de módulo, mas isso não é necessário. Basta usar o caminho de classe.
A propósito, você conhece o projeto GraalVM? Que tal usá-lo para criar o Maven?
Na semana passada, visitei o JavaZone e discuti isso com Chris e Oleg. Acho que precisaremos gastar algum tempo com isso, ver se é possível melhorar realmente o desempenho do Maven com o GraalVM. Pode ser interessante.
Você é o criador do Maven, um projeto que é muito importante para desenvolvedores de Java. Quais são seus sentimentos sobre isso?
Não sou o fundador do projeto, estou envolvido em seu apoio. Comecei a lidar com ele quando ele já havia percorrido um longo caminho, e parece que eu acho aceitável. Dez anos atrás, eu não pensaria que terminaria no topo da hierarquia, mas aconteceu, e é muito legal. Todo mundo tem uma opinião sobre o Maven, e eu realmente gosto disso quando você vem para a conferência, as pessoas aparecem e dizem que estão encantadas com o Maven. Isso me motiva muito e me fortalece para continuar trabalhando no projeto quando voltar para casa.
Muitos desenvolvedores odeiam veementemente o XML. Eu não sou um deles, mas quando se trata de criar sistemas, esse tópico sempre aparece devido ao pom.xml no Maven. Portanto, eu quero saber: qual é a sua opinião sobre XML?
O bom do XML é que todos o entendem, é fácil analisá-lo e pode fornecer um suporte muito bom no IDE. Eu sou bastante normal com XML, e até onde eu sei, entre os usuários do Maven, não mais que 5% odeiam XML - mas eles gritam alto! E você simplesmente nunca ouve os 95% restantes. No entanto, existe uma solução para esses 5% - aqui, novamente, quero mencionar o Takari. Há um projeto poliglota que permite selecionar uma sintaxe diferente. Portanto, se você deseja usar o Yaml e o pom.yml - isso é totalmente possível. Você só precisa adicionar extensões ao projeto e pode mudar para outro idioma.
E também sobre o humor dos desenvolvedores: lembro-me do tópico na lista de discussão do Maven, onde está o autor da ferramenta SDKMAN! a comunidade respondeu à proposta de distribuir através dele o Maven com frases como “tudo o que vejo é um projeto com um nome estúpido” e “você poderia vender melhor sua ideia”. Surgiram então discussões: alguns achavam que a comunidade havia reagido de forma muito agressiva, outros que a frase inicial "realizar ações adicionais em conexão com a minha ferramenta" era infundada. De uma maneira ou de outra, muitos estavam descontentes com a situação e, a esse respeito, a pergunta: você acha que especificamente o Maven ou a comunidade de código aberto em geral têm problemas de comunicação?
A comunicação pode ser muito, muito difícil, isso é certo. Especialmente quando isso acontece apenas através do texto e você não vê o interlocutor à sua frente - nessa situação, fica difícil explicar o que você quer dizer. Eu acho que todo projeto de código aberto enfrenta esse problema de se comunicar corretamente com as pessoas. Entendo perfeitamente por que os participantes do projeto às vezes se aborrecem - eles ouvem as mesmas perguntas repetidamente. Um exemplo dessa pergunta, que eu já mencionei - "por que você não pode usar o mvn clean install"? Parei de explicar isso, porque, caso contrário, eu me tornaria uma pessoa rude, mas não quero isso. Então, eu explico essas coisas de outras maneiras. Então, por um lado, a comunicação pode ser muito difícil. Por outro lado, embora Maven seja inflexível, faz parte de seu sucesso. Quando as pessoas apresentam ofertas incompatíveis com o nosso conceito Maven, apenas dizemos: desculpe, mas isso não nos serve por algum motivo. Entendo perfeitamente que isso pode ser frustrante. Mas, em geral, essa abordagem é apenas para o melhor.
Você poderia, no final, dizer algumas palavras aos nossos leitores, sugerir como eles podem chegar a um futuro brilhante?
Como eu disse, uma pequena equipe está trabalhando no Maven, é um projeto de código aberto no qual todos podem participar. Não é tão difícil. Criamos uma nova gravadora chamada para ganhar. Esses são problemas que não devem ser muito difíceis de resolver. Dessa forma, você pode conhecer como o Maven funciona. Se você quiser se juntar à nossa equipe, pelo exemplo de suas correções, veremos a qualidade do seu código - se você quiser ser notado por nós, recomendo que tente. Eu realmente gostaria que nossa equipe crescesse no futuro.
Obrigado pelas respostas. Encontre-me no Joker 2018!
Minuto de publicidade. A conferência Joker 2018 será realizada de 19 a 20 de outubro, na qual Robert fará uma apresentação sobre "O Apache Maven suporta TODOS Java" . Em geral, haverá muitos outros relatórios interessantes e dignos de nota no Joker. Os ingressos podem ser adquiridos no site oficial da conferência.