Oui, mais c'est juste ce qui ressort de mon expérience (mais je ne viens pas du java, ceci explique sûrement cela)
gestion des dépendances
Oui et non. Oui car la dépendance de maven est utilisée dans gradle par exemple. Non car gradle l'étend suffisamment pour ce que soit plus intéressant de se passer de maven.
cycle de vie du build
Celui de maven est une plaie. Impossible de faire facilement ce qu'on veut. Associé au côté purement déclaratif il est très complexe de faire ce qu'on souhaite.
Un exemple bidon : une webapp, à builder sous forme de war. Du code java et des fichiers js. Avant le packaging, compilation des fichiers js, minification, suppression des fichiers sources initiaux. En plus, modification dans certains fichiers de web-inf suivant un profile. Faire ça en maven c'est horrible voir impossible. On est alors résumé à, au mieux, utiliser ant (ce qui est absolument contraire au principe du déclaratif) ou faire un plugin maven (c'est pas bien compliqué, mais loin d'être quelque chose de logique, surtout si on doit en faire un par webapp)
Concernant JSF. JSF en soit n'est pas une trop mauvaise techno. Mais c'est, à mon avis, une mauvaise approche. Pour ma part, les interfaces c'est devenu du templating puissant, facilement (très) internationalisable, qui s'exécute aussi bien côté client que serveur. Avec ça aussi facile de faire de l'ajax, que du pas ajax, qu'un mélange des deux (par exemple en utilisant history). Et fini les composants js, une interface c'est du html, du css, du js simple. Fini la majorité des composants tout fait qui ne conviennent jamais. Le template sort d'ailleurs n'importe quelle donnée (je me sert parfois des templates pour me pondre de l'xml ou du json, bien bien plus agréable que d'utiliser des documents xml par exemple). L'interface au final c'est avant tout du html pur. (bon, ça ne veut pas dire qu'on utilise jamais autre chose hein, jamais de lib). Mais la lib elle est vraiment gérée côté client, pas côté serveur.
Je sais pas si c'est vraiment clair, mais en gros j'en suis totalement revenu du jsf, vaadin, etc. Même play ça ne me tente plus vraiment, je préfère vraiment ma soluce, un peu maison, beaucoup plus assemblage de composant. Je trouve ça plus pratique.
Ha ben non, pas des webservices quand même ! ;-)
Heureusement qu'il y a de quoi générer les wsdl (ou à partir) sans quoi ce serait vraiment horrible…
Bon, sinon, maven a des choses sympa, typiquement les archetypes. Je sais pas si un équivalent existe en gradle, au pire rien n'empêche, je pense, de créer un archetype pour faire un projet gradle. Enfin faut voir. Mais dans tous les cas c'est bien ça.
la simplicité et/ou l'intégration avec les IDE
C'est là où gradle est bien je trouve, lorsque je modifie mon fichier gradle, au mieux un coup de gradle eclipse et c'est ok. C'est sur que ce serait mieux si c'était intégré, mais j'ai même pas cherché.
la possibilité de virer maven, ant et des scripts par un seul outil
C'est bien, en partie, dans cet objectif que je pense l'utiliser
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 3.
Oui, mais c'est juste ce qui ressort de mon expérience (mais je ne viens pas du java, ceci explique sûrement cela)
Oui et non. Oui car la dépendance de maven est utilisée dans gradle par exemple. Non car gradle l'étend suffisamment pour ce que soit plus intéressant de se passer de maven.
Celui de maven est une plaie. Impossible de faire facilement ce qu'on veut. Associé au côté purement déclaratif il est très complexe de faire ce qu'on souhaite.
Un exemple bidon : une webapp, à builder sous forme de war. Du code java et des fichiers js. Avant le packaging, compilation des fichiers js, minification, suppression des fichiers sources initiaux. En plus, modification dans certains fichiers de web-inf suivant un profile. Faire ça en maven c'est horrible voir impossible. On est alors résumé à, au mieux, utiliser ant (ce qui est absolument contraire au principe du déclaratif) ou faire un plugin maven (c'est pas bien compliqué, mais loin d'être quelque chose de logique, surtout si on doit en faire un par webapp)
Concernant JSF. JSF en soit n'est pas une trop mauvaise techno. Mais c'est, à mon avis, une mauvaise approche. Pour ma part, les interfaces c'est devenu du templating puissant, facilement (très) internationalisable, qui s'exécute aussi bien côté client que serveur. Avec ça aussi facile de faire de l'ajax, que du pas ajax, qu'un mélange des deux (par exemple en utilisant history). Et fini les composants js, une interface c'est du html, du css, du js simple. Fini la majorité des composants tout fait qui ne conviennent jamais. Le template sort d'ailleurs n'importe quelle donnée (je me sert parfois des templates pour me pondre de l'xml ou du json, bien bien plus agréable que d'utiliser des documents xml par exemple). L'interface au final c'est avant tout du html pur. (bon, ça ne veut pas dire qu'on utilise jamais autre chose hein, jamais de lib). Mais la lib elle est vraiment gérée côté client, pas côté serveur.
Je sais pas si c'est vraiment clair, mais en gros j'en suis totalement revenu du jsf, vaadin, etc. Même play ça ne me tente plus vraiment, je préfère vraiment ma soluce, un peu maison, beaucoup plus assemblage de composant. Je trouve ça plus pratique.
Ha ben non, pas des webservices quand même ! ;-)
Heureusement qu'il y a de quoi générer les wsdl (ou à partir) sans quoi ce serait vraiment horrible…
Bon, sinon, maven a des choses sympa, typiquement les archetypes. Je sais pas si un équivalent existe en gradle, au pire rien n'empêche, je pense, de créer un archetype pour faire un projet gradle. Enfin faut voir. Mais dans tous les cas c'est bien ça.
C'est là où gradle est bien je trouve, lorsque je modifie mon fichier gradle, au mieux un coup de gradle eclipse et c'est ok. C'est sur que ce serait mieux si c'était intégré, mais j'ai même pas cherché.
C'est bien, en partie, dans cet objectif que je pense l'utiliser