Admettez, nous avons tous travaillé sur la construction de bâtiments à Maven pendant de longues soirées et nuits, et à ce moment-là, je voulais vraiment parler à quelques créateurs affectueux de cette merveilleuse technologie. Parfois, les rêves deviennent réalité! Zhenya et moi (
phillennium )
avons rencontré presque le développeur Maven le plus important - Robert Scholte. Et ce que nous lui avons demandé ...
En savoir plus →
Avec le nouveau cycle de sortie, les versions Java sortent les unes après les autres, la onzième est déjà apparue, tandis que beaucoup sont assises sur la huitième. Vous allez bientôt faire une présentation sur la façon dont Maven soutient tout cela, et vous ne voulez pas gâcher le rapport, mais posez une question dans ce sens. Que pensez-vous personnellement de ce nouveau cycle de sortie qui vous apporte du travail? Est-ce un changement pour le meilleur ou pour le pire?
Si vous parlez d'un cycle de sortie de 6 mois, alors pour Maven, c'est un peu rapide. Notre équipe est assez petite, nous avons environ 5 à 10 participants actifs, et ils sont tous bénévoles, aucune entreprise ne développe Maven. Donc, tout le monde devrait travailler sur le projet pendant son temps libre. Les changements en Java créent beaucoup de travail. Chaque fois qu'une nouvelle version est publiée, nous devons fournir son support, ce qui signifie que nous n'avons pas le temps pour Maven, ses plugins ou autre chose. Ce serait mieux pour moi si le cycle durait un an ou demi.
D'autres personnes développant des projets pour l'écosystème Java ont-elles le même sentiment, qui ont également besoin de prendre en charge les dernières versions?
À en juger par Twitter, alors oui, la plupart conviennent que 6 mois est trop rapide.
Pourriez-vous raconter l'histoire de Maven? Si je me souviens bien, il a été créé il y a longtemps pour rendre la construction de la turbine Apache moins effrayante et douloureuse. Soit dit en passant, j'ai utilisé Apache Turbine. Tu te souviens de cette fois?
L'histoire de Maven a commencé il y a longtemps. J'ai rejoint le projet il y a environ 8 ans, c'est-à-dire pendant la version 3.0.3 ou 3.0.4. Et à ce stade, Maven existe depuis un certain temps. Pour autant que je sache, il faisait partie du projet Turbine. Un outil séparé a été fabriqué à partir d'une partie de ce projet, qui est devenu Maven. J'ai, comme probablement tout, utilisé Ant alors. Je n'aimais pas cela chaque fois que je commençais à travailler sur un nouveau projet, j'avais besoin de copier tous ces fichiers Ant. Je savais qu'il devait y avoir une meilleure solution, j'ai commencé à la rechercher sur Internet et j'ai trouvé Maven. Cependant, avant de comprendre l'idée principale de Maven, beaucoup de temps s'est écoulé. Cependant, lorsque vous le comprenez, cela devient pratique. Tous les problèmes que j'avais avec Ant ont disparu. Ant est toujours un excellent outil, mais si vous travaillez sur un projet qui combine de nombreuses sources, je recommande fortement Maven ou un outil similaire.
Maven concerne Java. J'ai essayé de l'utiliser pour C ++, mais ce n'était pas très agréable. Y a-t-il un moment où Java ne sera plus, et que ferons-nous alors?
Parmi les langages orientés objet populaires existants, Java semble être l'un des plus anciens, il a déjà plus de 20 ans. Je n'ai pas regardé les dernières statistiques, mais je suis sûr que Java est encore très répandu. Je pense que cela existera pendant un certain temps. Du moins, je l'espère - cela signifie que je ne resterai pas sans travail.
Maven va-t-il vivre trop longtemps?
Mais c'est une question difficile. Jusqu'à aujourd'hui, 65 à 80% des projets Java utilisent Maven. Même pour un produit de plus de 15 ans, c'est beaucoup. Probablement, beaucoup plus peut être amélioré dans Maven. Nous avons des idées pour Maven 4 et même Maven 5. Mais il faudra beaucoup de temps pour les mettre en œuvre. Je pense que l'idée générale de Maven ne deviendra pas obsolète, mais d'autres systèmes d'assemblage pourraient bien la dépasser. Parce qu'ils tirent de l'expérience à la fois des erreurs que nous avons faites chez Maven et des décisions que nous avons prises correctement, et sur la base de cette expérience, ils peuvent partir de zéro. L'un des avantages de Maven est la compatibilité descendante. Même un projet écrit il y a 10 ou 15 ans peut être assemblé à l'aide de la dernière version de Maven. Mais à cause de cela, nous avons beaucoup d'ancien code dans Maven Core. Il faut le remplacer, mais ce n'est pas si facile.
Pour autant que je m'en souvienne, vous pouvez maintenant construire des moji sans annotations.
Oui c'est possible.
Avant l'entretien, j'ai essayé de trouver un tutoriel à ce sujet et je n'ai rien trouvé. C'est comme si les langoliers nous poursuivaient et rongeaient tous les vieux documents sur Internet. Mais je me souviens qu'il était une fois aucune annotation et que des conventions spéciales étaient utilisées. Eh bien lui, passons à une autre question. Pensez-vous que Maven a une réelle concurrence? Dites Gradle?
Gradle est un compétiteur très fort, et il existe depuis un certain temps. Je pense que la concurrence est bonne, car elle nous maintient en forme et nous permet de voir des solutions alternatives. Ils ont juste une approche différente sur la façon de collecter des projets, il n'y a rien de mal à cela. Chacun devrait choisir ce qui convient le mieux à son projet. Je devrais peut-être aussi mentionner pro ici . Il s'agit d'un outil écrit par Remi Forax de l'équipe ASM (analyseur de bytecode). Il était, comme moi, membre du groupe d'experts du projet Jigsaw. Il voulait écrire un outil de construction qui reflétait le mieux les idées Java. Lors de la création pro, il a emprunté les meilleurs aspects de Maven. Regarder cela était intéressant. Il s'agissait d'une démonstration conçue pour montrer que vous pouvez utiliser les modules Java 9 et les avantages associés dans le générateur.
Vous avez dit que vous avez participé au projet Jigsaw - et vous l'avez dit au passé. Il a cessé d'exister? A-t-il encore la possibilité de se développer?
Ce JSR est fermé. Certes, certains problèmes non résolus sont restés, mais ils sont désormais traités par l'équipe de support.
Qu'est-ce qui a causé le plus de difficultés à développer Maven? Quels ont été les problèmes les plus graves? Pas en termes de Java 9, mais en général, basé sur toute l'expérience de développement. Pouvez-vous choisir, disons, les deux problèmes les plus importants?
La question n'est pas facile, mais essayons. La partie dans laquelle se produit la résolution des dépendances est extrêmement complexe. Nous essayons toujours de l'améliorer. Vous avez peut-être remarqué qu'il n'y avait pas de version Maven 3.4, après la version 3.3.9, il y avait immédiatement 3.5.0. La raison principale en est qu'il y a eu des changements importants dans la résolution des dépendances. Ils ont été marqués comme correctifs de bogues, mais nous avons remarqué qu'un nombre important de projets étaient soudainement interrompus - ils dépendaient de ces étranges changements. C'était inacceptable. Par conséquent, nous avons fait ce que nous n'aurions pas pris dans d'autres circonstances - un référentiel git à réinitialisation matérielle, et dans Maven 3.5.0, nous avons commencé à sélectionner uniquement des améliorations externes. Eh bien, et bien sûr, nous avons rendu la console multicolore - tout le monde l'a aimé.
Ok, c'est maintenant la deuxième difficulté!
Il n'a pas été facile pour nous de trouver un lien avec la communauté Maven et de leur apprendre à utiliser correctement l'outil.
Donc tout le monde sait comment utiliser Maven: copiez quelques footstraps XML à partir des commentaires sur Stack Overflow, et ça marche. N'est-ce pas?
Et bien. Non. Je suis sûr que le plus souvent, il vous sera conseillé de faire une installation propre, et ce n'est pas vrai. Donc, probablement, cela devrait être fait dans Maven 2. Vous devez maintenant exécuter mvn verify. Parce que lorsque vous nettoyez, tout est supprimé, tout le résultat du travail. Et si les fichiers sont copiés à partir de vous - ce sont des opérations d'E / S, elles sont lentes. En général, beaucoup de choses seront faites plusieurs fois. La plupart des plugins savent quand ils doivent faire leur travail. En règle générale, il n'est pas nécessaire de nettoyer. Quant à l'installation, cette commande copie uniquement vos fichiers JAR dans le référentiel local. Il s'agit là encore d'une opération d'E / S inutile. De plus, votre référentiel local peut devenir sale, c'est-à-dire qu'il peut être différent du référentiel local de votre collègue. Parfois, cela peut conduire à des résultats intéressants. Vous devez donc simplement exécuter mvn verify, cela suffit.
Soit dit en passant, je viens d'ouvrir maven.apache.org , et il est écrit: «Apache Maven est un outil de gestion et de compréhension de projets logiciels». Mais beaucoup de gens pensent que Maven n'est qu'un autre outil de construction. Quelle est la différence entre un outil d'assemblage et un outil de gestion de projet?
Il vaut probablement mieux ne pas répondre à cette question - ce n’est pas moi qui l’ai écrit sur le site. Je pense que l'auteur voulait dire que Maven est bien plus que la simple construction d'un projet. Il est également impliqué dans la résolution des dépendances, il fournit un format de configuration, il permet de ne pas installer trop de choses. En général, c'est une énorme collection de tout dans le monde.
Quels sont les principaux principes et convictions de l'équipe Maven? Par exemple, pensent-ils qu'une approche déclarative vaut mieux qu'un impératif? Quelque chose comme Zen en Python. Avez-vous un ensemble de règles similaire?
Je pense que non. À notre avis, la configuration des plugins doit être aussi simple que possible. Si des défauts raisonnables existent, ils doivent être indiqués. Cela facilitera la vie de l'utilisateur final. Pour la première fois depuis de nombreuses années, nous avons récemment modifié l'option par défaut pour les versions source et cible - avant c'était 1.5, maintenant c'est 1.6. Nous voulions que l'option par défaut soit présente, car sans elle, la version utilisée dans le JDK est utilisée. Dans ce cas, si j'utilise Java 10 et que quelqu'un d'autre utilise Java 12, nous aurons des résultats différents. Vous devez toujours spécifier la source et la cible. Mais si vous avez commencé à utiliser Java 9, vous ne pouvez plus créer Hello World avec un simple fichier pom et une classe, car Java 9 nécessite au moins Java 6 pour les valeurs source et cible. Par conséquent, nous avons décidé de créer la version 1.6 par défaut et ajouté un avertissement que si vous n'avez pas encore spécifié de version, cela devrait être fait - les gens doivent savoir que vous devez définir les versions source et cible ou la valeur de version si vous travaillez avec Java 9. Ou les deux.
Quelles difficultés voyez-vous pour Maven à l'avenir? Vous avez dit que vous essayez de ne pas trop changer Maven. Et pourtant, qu'est-ce qui nous attend dans le futur?
L'un des changements les plus importants que nous souhaitons apporter concerne le fichier pom. Nous avons constaté que dans certaines sections - en particulier dans la construction - ce serait bien d'ajouter des éléments supplémentaires. Mais pour l'instant, nous ne pouvons pas le faire. Le même fichier pom que vous utilisez sur votre système est téléchargé. Si vous y ajoutez d'autres éléments, ils violeront le XSD et d'autres outils ne pourront pas l'utiliser.
Mais pouvez-vous changer le XSD dans l'en-tête?
Oui Mais je ne pense pas que chaque outil vérifie le XSD. Ils pensent juste qu'ils ont affaire à la version 4.0.0. Il sera donc très difficile d'apporter des changements. Nous avons décidé de diviser le fichier pom en plusieurs parties et de commencer avec le Build POM. Et celui qui sera déchargé s'appellera Consumer POM. Il sera généré sur la base du Build POM et aucune autre action n'est requise. Et il sera entièrement compatible avec Maven POM 4.0.0. En divisant le POM en deux parties, nous pouvons enfin l'améliorer considérablement et rendre Maven plus facile à utiliser. Il s'agit d'un changement dans le noyau Maven, et nous y travaillons depuis plus d'un an, y compris la mise en œuvre dans l'IDE. Ce n'est pas facile.
Certains IDE tentent d'inclure des parties de Maven dans l'IDE pour des raisons d'intégration, d'auto-complétion, de compilation incrémentielle, etc. Comment bien faire? Pour autant que je m'en souvienne, certaines parties de Maven ont été construites dans Eclipse il y a longtemps.
Je pense que de telles tentatives sont justifiées - ce système était très pratique pour les utilisateurs en raison de l'intégration. Cela a été rendu possible grâce à l'un des changements importants mis en œuvre dans Maven 3. L'architecture a été refaite pour fournir un meilleur support dans l'IDE. Les auteurs de ces changements ont travaillé en étroite collaboration avec Eclipse, et cette solution est venue d'ici. Je pense que cela est permis. Je sais que NetBeans et InelliJ ont une approche complètement différente, ils appellent simplement Maven depuis la ligne de commande sans aucune intégration.
Un autre sujet important est la vitesse de Maven. Pouvons-nous en quelque sorte l'augmenter? La résolution des dépendances et les opérations d'E / S sont très lentes. Aujourd'hui encore sur un SSD.
Oui, quelque chose peut être fait. Vous devez d'abord regarder combien de noyaux sont dans votre système et démarrer Maven avec plusieurs threads. C'est une des solutions. Jetez également un œil à Takari. Il s'agit d'une entreprise créée par Jason van Zayl, l'un des fondateurs de Maven. Il a écrit quelques extensions intéressantes et considérablement amélioré la prise en charge des assemblages parallèles, c'est-à-dire lorsque vous créez plusieurs projets. J'espère qu'un jour il donnera ces développements à Maven, mais pour l'instant vous devriez jeter un œil à sa page.
Vous avez dit que vous travailliez sur Maven pendant votre temps libre, non? Le fait que vous soyez l'un des créateurs de Maven vous aide-t-il dans votre travail actuel? Ou est-ce juste un hobby?
Je travaille comme architecte logiciel dans une organisation gouvernementale aux Pays-Bas. Voilà comment je gagne ma vie. Bien sûr, ils savent que je travaille également sur Maven, ils me posent donc régulièrement des questions sur Maven. Mais dans l'ensemble, je ne suis que leur architecte. Et le soir, je travaille sur Maven, j'essaye de l'améliorer, j'aide les gens.
Travaillez-vous sur d'autres projets open source en dehors de Maven?
Je participe à deux autres projets. L'un s'appelle MojoHaus, il a développé une partie importante des plugins pour Maven. C'est vrai, maintenant je fais peu de choses dans ce projet, mais parfois je regarde dedans et je règle différentes petites choses. Un autre projet s'appelle QDox. Il analyse le code source. Il est également associé à Maven, car il est utilisé dans certains plugins pour cela. Cette expérience m'aide, car, par exemple, dans le cas du descripteur de module, introduit dans Java 9, l'expérience m'a permis d'utiliser un descripteur dans les plugins pour Maven.
Au fait, quelle est votre opinion sur Java 9, 10, 11? Dois-je les utiliser, ou est-il préférable de rester avec Java 8?
Migrez vers des versions plus récentes. Même si vous n'utilisez pas toutes les fonctionnalités, vous devez mettre à niveau vers Java 10, ou attendre quelques semaines et mettre à niveau vers Java 11. Utilisez simplement le chemin de classe. Java est beaucoup plus rapide grâce à sa modularité, mais le chemin de classe fonctionne juste. Je sais que beaucoup pensent encore que vous devez ajouter un descripteur de module ou utiliser un système de modules, mais ce n'est pas nécessaire. Utilisez simplement classpath.
Au fait, connaissez-vous le projet GraalVM? Que diriez-vous de l'utiliser pour construire Maven?
La semaine dernière, j'ai visité JavaZone et en ai discuté avec Chris et Oleg. Je pense que nous devrons passer un peu de temps avec cela, voir s'il est possible d'améliorer vraiment les performances de Maven avec GraalVM. Ça pourrait être intéressant.
Vous êtes le créateur de Maven, un projet très important pour les développeurs Java. Quels sont vos sentiments à ce sujet?
Je ne suis pas le fondateur du projet, je suis engagé dans son soutien. J'ai commencé à traiter avec lui alors qu'il avait déjà parcouru un long chemin, et il semble que je trouve cela acceptable. Il y a dix ans, je n'aurais pas pensé que je finirais au sommet de la hiérarchie, mais c'est arrivé, et c'est très cool. Tout le monde a une opinion sur Maven, et j'aime vraiment ça quand vous venez à la conférence, les gens viennent et disent qu'ils sont ravis de Maven. Cela me motive beaucoup et me donne la force de continuer à travailler sur le projet à mon retour.
De nombreux développeurs détestent vivement XML. Je ne suis pas l'un d'eux, mais quand il s'agit de construire des systèmes, ce sujet apparaît toujours en raison de pom.xml dans Maven. Par conséquent, je veux savoir: quelle est votre opinion sur XML?
La bonne chose à propos de XML est que tout le monde le comprend, il est facile de l'analyser et il peut fournir un très bon support dans l'EDI. Je suis tout à fait normal avec XML, et pour autant que je sache, parmi les utilisateurs de Maven, pas plus de 5% détestent XML - mais ils le crient fort! Et vous n'entendez tout simplement jamais les 95% restants. Néanmoins, il existe une solution pour ces 5% - ici encore, je veux mentionner Takari. Il existe un projet polyglotte qui vous permet de sélectionner une syntaxe différente. Donc, si vous souhaitez utiliser Yaml et pom.yml - c'est tout à fait possible. Vous avez juste besoin d'ajouter des extensions au projet et vous pouvez basculer vers une autre langue.
Et aussi sur l'humeur des développeurs: je me souviens du fil de discussion sur la liste de diffusion Maven, où est l'auteur de l'outil SDKMAN! la communauté a répondu à la proposition de distribuer à travers elle le Maven avec des phrases comme «tout ce que je vois est un projet avec un nom stupide» et «vous pourriez mieux vendre votre idée». Des discussions ont alors eu lieu: certains ont estimé que la communauté avait réagi de manière trop agressive, d'autres que la phrase initiale «faire des actions supplémentaires en rapport avec mon outil» n'était pas fondée. D'une manière ou d'une autre, beaucoup étaient mécontents de la situation, et à cet égard la question: pensez-vous que spécifiquement Maven ou la communauté open-source en général ont des problèmes de communication?
La communication peut être très, très difficile, c'est sûr. Surtout lorsque cela se produit uniquement à travers le texte et que vous ne voyez pas l'interlocuteur devant vous - dans cette situation, il devient difficile d'expliquer ce que vous voulez dire. Je pense que chaque projet open source est confronté à ce problème de communication correcte avec les gens. Je comprends parfaitement pourquoi les participants au projet sont parfois ennuyés - ils entendent sans cesse les mêmes questions. Un exemple d'une telle question, que j'ai déjà mentionnée - "pourquoi ne pouvez-vous pas utiliser mvn clean install"? J'ai arrêté d'expliquer cela, car sinon je serais devenu une personne impolie, mais je ne veux pas ça. J'explique donc ces choses d'une autre manière. Ainsi, d'une part, la communication peut être très difficile. En revanche, bien que Maven soit inflexible, cela fait partie de son succès. Lorsque les gens proposent des offres incompatibles avec notre concept Maven, nous disons simplement: désolé, mais cela ne nous convient pas pour une raison quelconque. Je comprends parfaitement que cela peut être frustrant. Mais en général, cette approche n'est que pour le mieux.
Pourriez-vous, à la fin, dire quelques mots à nos lecteurs, suggérer comment ils peuvent arriver à un brillant avenir?
Comme je l'ai dit, une petite équipe travaille sur Maven, c'est un projet open source auquel tout le monde peut participer. Ce n'est pas si difficile. Nous avons créé un nouveau label appelé à gagner. Ce sont des problèmes qui ne devraient pas être trop difficiles à résoudre. De cette façon, vous pouvez apprendre comment fonctionne Maven. Si vous souhaitez rejoindre notre équipe, alors par l'exemple de vos correctifs, nous verrons la qualité de votre code - si vous voulez être remarqué par nous, alors je vous recommande de l'essayer. J'aimerais vraiment que notre équipe grandisse à l'avenir.
Merci pour les réponses. Retrouvez-moi au Joker 2018!
Minute de publicité. La conférence Joker 2018 se tiendra les 19 et 20 octobre, au cours de laquelle Robert fera une présentation sur "Apache Maven prend en charge TOUS Java" . En général, il y aura de nombreux rapports plus intéressants et dignes de mention chez Joker. Les billets peuvent être achetés sur le site officiel de la conférence.