J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.
Et pourtant, Maven n'est pas une surcouche à Ant, mais bien un outil à part entière. Maven est à une couche d'abstraction de plus haut niveau que celle de Ant et autres outils similaires dans la construction logicielle.
on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code.
Oui, seulement Maven n'est pas pour écrire du code ;-)
Sinon, effectivement, l'usage du XML pour écrire le POM peut être pour certain considéré comme rébarbatif. Je ne suis moi même pas sûr que ce choix soit pertinent ; seulement, à l'heure du tout XML, bien que critiquable, je comprends le choix de celui-ci par les concepteurs de Maven.
Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local,
Ce qui est téléchargé de l'extérieur ce sont seulement les plugins ou dépendances qui ne sont pas présents dans le cache local (dépôt local). Une fois, téléchargés, seuls ceux présents dans le cache local sont pris en compte. Donc, au début, c'est lourd, mais après ça va très vite. De plus, l'usage de Maven dans de l'intégration continue m'est apparu plus facile qu'avec d'autres solutions.
la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE
Là je ne suis pas d'accord. Que la structure plaise ou non est une chose. Elle a sa propre logique et, que l'on aime ou pas, elle est cohérente pour bcp types de projets, et pas essentiellement pour du J2EE/JEE. Elle a l'avantage de proposer une structure commune aux projets, ce qui fait que les développeurs n'ont pas à réapprendre de comment celui-ci est structuré, de comment sont gérées les dépendances, etc. (Oui, effectivement, il doit connaitre celui de Maven, mais cet acquis est capitalisable.)
Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).
Oui, mais ça reste toujours des définitions de tâches qui sont pré-écrites dans les Makefile ou autres fichiers de build. L'enchaînement des tâches y doivent aussi être décrites. Dans Maven, l'accent est mis non plus sur les tâches, mais sur les phases d'écriture de code, Maven gérant le flot qui parcours les phases.
Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).
Oui, d'accord. Mais je ne pense pas que ça empêche la création d'outil pour C/C++ similaires à Maven ; il faut prendre en compte je pense les particularités de cet environnement.
La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect
Oui, une certaine richesse. Et c'est justement la pauvreté d'outils de type Maven, cad d'outils de construction logicielle de plus haut niveau, que je trouve dommage. Probablement que c'est encore tôt.
[^] # Re: Ant like. A quand un maven like ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à -1.
J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.
Et pourtant, Maven n'est pas une surcouche à Ant, mais bien un outil à part entière. Maven est à une couche d'abstraction de plus haut niveau que celle de Ant et autres outils similaires dans la construction logicielle.
on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code.
Oui, seulement Maven n'est pas pour écrire du code ;-)
Sinon, effectivement, l'usage du XML pour écrire le POM peut être pour certain considéré comme rébarbatif. Je ne suis moi même pas sûr que ce choix soit pertinent ; seulement, à l'heure du tout XML, bien que critiquable, je comprends le choix de celui-ci par les concepteurs de Maven.
Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local,
Ce qui est téléchargé de l'extérieur ce sont seulement les plugins ou dépendances qui ne sont pas présents dans le cache local (dépôt local). Une fois, téléchargés, seuls ceux présents dans le cache local sont pris en compte. Donc, au début, c'est lourd, mais après ça va très vite. De plus, l'usage de Maven dans de l'intégration continue m'est apparu plus facile qu'avec d'autres solutions.
la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE
Là je ne suis pas d'accord. Que la structure plaise ou non est une chose. Elle a sa propre logique et, que l'on aime ou pas, elle est cohérente pour bcp types de projets, et pas essentiellement pour du J2EE/JEE. Elle a l'avantage de proposer une structure commune aux projets, ce qui fait que les développeurs n'ont pas à réapprendre de comment celui-ci est structuré, de comment sont gérées les dépendances, etc. (Oui, effectivement, il doit connaitre celui de Maven, mais cet acquis est capitalisable.)
Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).
Oui, mais ça reste toujours des définitions de tâches qui sont pré-écrites dans les Makefile ou autres fichiers de build. L'enchaînement des tâches y doivent aussi être décrites. Dans Maven, l'accent est mis non plus sur les tâches, mais sur les phases d'écriture de code, Maven gérant le flot qui parcours les phases.
Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).
Oui, d'accord. Mais je ne pense pas que ça empêche la création d'outil pour C/C++ similaires à Maven ; il faut prendre en compte je pense les particularités de cet environnement.
La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect
Oui, une certaine richesse. Et c'est justement la pauvreté d'outils de type Maven, cad d'outils de construction logicielle de plus haut niveau, que je trouve dommage. Probablement que c'est encore tôt.
Maven est un peu calqué sur le modèle Windows.
Hooo ! Et en quoi ?