Bonjour, Je me pose la question de comment gérer les dépendances javascript : - Normalement, avec nuiton-js. Mais j'ai un module angular-translate que n'est pas pris en charge, ni d’éditeur WYSIWYG - Alternatif, Il existe un gestionnaire de dépot 'bower' qui est une sorte de maven pour javascript. Toutes les libs javascripts sont présent avec presque toutes les versions. Le problème c'est que bower est une appli installé avec npm donc les dépendances sont un peu lourde - CDN, la version actuel est avec des dépots web, ça a l'avantage de pas créer de charge serveur ni gérer les versions, mais celà implique une forte dépendance a l’hébergeur. On peut faire confiance au dépot google (angular), mais peut être un peu moins a cdnjs que je ne connaissais pas avant le stage. Voilà. Il faudrait faire un choix sur l'une des solutions. Mon avis : laisser pollen les dépots web : - Impossible de customisé les lib (comme j'ai fait avec ckeditor) - Impossible d'avoir l'application sur un réseau local sans internet + Version Optimisé pour les performances Pollen avec les dépots nuiton-js : - Faut prendre le temps d'ajouter le lib qui n'y sont pas : angular-translate, ckeditor ou un autre editeur WYSIWIG + Dépendance géré par maven. Pollen avec les dépôts géré par bower : - Bower dépend de Node (npm) + Plus facile de modifier les versions des dépendances + Une ligne de commande pour installer toutes les dépendances ('bower install', exécutable par maven si on veut) + Outils connu donc qui peut être utilisé par une communauté Quelle solution on envisage pour pollen ? Cordialement, Adrien
Le 16/06/2014 18:05, a.garandel@dralagen.fr a écrit :
Bonjour, Yo, Je me pose la question de comment gérer les dépendances javascript :
- Normalement, avec nuiton-js. Mais j'ai un module angular-translate que n'est pas pris en charge, ni d’éditeur WYSIWYG On peut les packager, c'est libre. On peut aussi utiliser la release de webjars : http://repo1.maven.org/maven2/org/webjars/angular-translate
- Alternatif, Il existe un gestionnaire de dépot 'bower' qui est une sorte de maven pour javascript. Toutes les libs javascripts sont présent avec presque toutes les versions. Le problème c'est que bower est une appli installé avec npm donc les dépendances sont un peu lourde À terme, ca me tente bien cette approche. À vouloir "repousser" dans maven c'est lib javascript qui existe déjà ailleurs, c'est de la pure duplication.
Lié l’écosystème java à écosystème javascript est la meilleure solution à long terme.
- CDN, la version actuel est avec des dépots web, ça a l'avantage de pas créer de charge serveur ni gérer les versions, mais celà implique une forte dépendance a l’hébergeur. On peut faire confiance au dépot google (angular), mais peut être un peu moins a cdnjs que je ne connaissais pas avant le stage.
C'est fiable, mais il nous arrive de faire des applications purement 'intranet' sans accès internet, donc cela ne fonctionne pas.
Voilà. Il faudrait faire un choix sur l'une des solutions.
Mon avis :
laisser pollen les dépots web : - Impossible de customisé les lib (comme j'ai fait avec ckeditor)
Il faut éviter au maximum, car c'est toujours très compliqué à mettre à jour.
- Impossible d'avoir l'application sur un réseau local sans internet + Version Optimisé pour les performances
Pollen avec les dépots nuiton-js : - Faut prendre le temps d'ajouter le lib qui n'y sont pas : angular-translate, ckeditor ou un autre editeur WYSIWIG + Dépendance géré par maven.
Pollen avec les dépôts géré par bower : - Bower dépend de Node (npm) + Plus facile de modifier les versions des dépendances + Une ligne de commande pour installer toutes les dépendances ('bower install', exécutable par maven si on veut) + Outils connu donc qui peut être utilisé par une communauté
Quelle solution on envisage pour pollen ?
La finalité est que : - 'mvn clean install' package totalement l'application - 'mvn jetty:run' fonctionne - dans eclipse cela fonctionne Donc, la seule solution que je vois à l'heure actuelle est d'avoir les resources javascript dans les jars (et seul nuiton-js, webjars propose ca). Le must au final serait truc maven + bower. (attention, la suite est sujette à troll, et aurait plus eu sa place un vendredi) Après, concernant pollen-ui-angular, ce n'est pas un projet Java, qu'apporte vraiment Maven dans ce cas ? Peut-être que la solution peut se trouver dans d'autres ecosystème, comme Gradle. Gradle n'est déjà pas spécifique à Java, et doit avoir moins de contrainte que Maven. À voir son intégration avec Bower, yeoman, et grunt. Mais le problème n'est pas simple. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 16/06/2014 18:05, a.garandel@dralagen.fr a écrit :
Bonjour, Yo,
On Mon, 16 Jun 2014 19:22:41 +0200 Eric Chatellier <chatellier@codelutin.com> wrote: ola
Quelle solution on envisage pour pollen ?
La finalité est que : - 'mvn clean install' package totalement l'application mvn clean package alors ? - 'mvn jetty:run' fonctionne
ou mvn tomcat7:run... Jetty is evil :(
- dans eclipse cela fonctionne No comment.
Donc, la seule solution que je vois à l'heure actuelle est d'avoir les resources javascript dans les jars (et seul nuiton-js, webjars propose ca).
Le must au final serait truc maven + bower.
+1 Si y'a un plugin à faire, let's do it!
Après, concernant pollen-ui-angular, ce n'est pas un projet Java, qu'apporte vraiment Maven dans ce cas ?
C'est la seule solution qu'on a pour le moment pour déployer facilement sur demo (autre chose de faire des git pull sur un serveur de demo...) Il me parait un peu compliqué à l'heure actuelle de changer ça d'autant plus que le reste du projet est construit avec maven. On pourait imaginer créer un autre projet (sous-projet ?) sur la forge pollen-ui qui du coup ne serait plus dans le build des services ? Perso avant de tout changer je serais plutôt partisan de voir ce qui se fait ailleurs sous maven et si y'a vraiment aucune solution se tourner vers un autre outil de build, mais pas avant (a.k.a nuiton-js). Pour moi maven n'est pas forcement pour produire du java, on peut définir de nouveaux packaging, et les rattacher au cycle de vie de maven. Cela existe déjà pour le packaging javascript il me semble.
Peut-être que la solution peut se trouver dans d'autres ecosystème, comme Gradle. Gradle n'est déjà pas spécifique à Java, et doit avoir moins de contrainte que Maven.
À voir son intégration avec Bower, yeoman, et grunt.
Autant regarder d'abord pour maven. Comme dit précemment, on peut définir un nouveau type de packaging et faire en sorte que maven fasse exactement ce qu'on veut. Par exemple définir le bon enchainement des plugins à déclancher selon les phases des cycles de vie. Ça me parait une bonne piste à creuser. Il suffit alors juste de définir un nouvelle convention sur comment on veut packager un projet html + javascript. Cela vaudrait peut-être le coup de voir avec les gens de Maven, on ne doit pas être les seuls à vouloir faire ça... My 2 cents. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Hello ! Le Mon, 16 Jun 2014 19:22:41 +0200, Eric Chatellier <chatellier@codelutin.com> a écrit :
Le 16/06/2014 18:05, a.garandel@dralagen.fr a écrit :
- Alternatif, Il existe un gestionnaire de dépot 'bower' qui est une sorte de maven pour javascript. Toutes les libs javascripts sont présent avec presque toutes les versions. Le problème c'est que bower est une appli installé avec npm donc les dépendances sont un peu lourde
À terme, ca me tente bien cette approche. À vouloir "repousser" dans maven c'est lib javascript qui existe déjà ailleurs, c'est de la pure duplication.
Lié l’écosystème java à écosystème javascript est la meilleure solution à long terme. [...] La finalité est que : - 'mvn clean install' package totalement l'application - 'mvn jetty:run' fonctionne - dans eclipse cela fonctionne
Donc, la seule solution que je vois à l'heure actuelle est d'avoir les resources javascript dans les jars (et seul nuiton-js, webjars propose ca).
Le must au final serait truc maven + bower.
Je suis pleinement d'accord avec cela. Il faut s'appuyer sur la communauté Javascript autant que possible pour nous simplifier la vie et garder un modèle qui permettra aux gens de se retrouver avec du "classique" et faciliter les contributions \o/
(attention, la suite est sujette à troll, et aurait plus eu sa place un vendredi)
Après, concernant pollen-ui-angular, ce n'est pas un projet Java, qu'apporte vraiment Maven dans ce cas ?
Ici, ça apporte une forme de cohésion avec tout le projet : ce n'est pas seulement une hsitoire de pollen-ui-angular, c'est le projet Pollen au complet. Actuellement, je n'arrive pas à concevoir l'ui de pollen comme un projet à part de Pollen
Peut-être que la solution peut se trouver dans d'autres ecosystème, comme Gradle. Gradle n'est déjà pas spécifique à Java, et doit avoir moins de contrainte que Maven.
À voir son intégration avec Bower, yeoman, et grunt.
Mais le problème n'est pas simple.
-- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
participants (4)
-
a.garandel＠dralagen.fr -
Eric Chatellier -
Tony Chemit -
Yannick Martel