- Nuiton-js-devel - mailman.cloud.codelutin.com

Dépendance de nuiton-js-wro sur wro4j-maven-plugin
by Eric Chatellier Jan. 30, 2013

Jan. 30, 2013

Salut, Le trunk a un peu bougé et il est problématique d'avoir une dépendance runtime sur nuiton-js-wro qui tire wro4j-maven-plugin (aussi en runtime) qui lui même tire: - slf4j-log4j (encore lui) : bug double implémentation de slf4j - guice - api maven - et plein d'autre Tout ca pour la servlet wro. C'est possible de spliter un module servlet et un module plugin ? -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

2 1

Re: [Nuiton-js-devel] [Nuiton-js-commits] r10 - in trunk: . nuiton-js-bootstrap nuiton-js-bootstrap/src nuiton-js-bootstrap/src/main nuiton-js-bootstrap/src/main/resources nuiton-js-bootstrap/src/main/resources/META-INF nuiton-js-bootstrap/src/main/resources/META-INF/nuiton-js nuiton-js-bootstrap/src/main/resources/nuiton-js-bootstrap nuiton-js-bootstrap/src/main/resources/nuiton-js-bootstrap/css nuiton-js-bootstrap/src/main/resources/nuiton-js-bootstrap/img nuiton-js-bootstrap/src/main/resources/nuiton-js-
by Tony Chemit Dec. 31, 2012

Dec. 31, 2012

On Mon, 31 Dec 2012 18:22:37 +0100 (CET) bpoussin(a)users.nuiton.org wrote: > Added: trunk/nuiton-js-bootstrap/pom.xml > =================================================================== > (Binary files differ) > > > Property changes on: trunk/nuiton-js-bootstrap/pom.xml > ___________________________________________________________________ > Added: svn:mime-type > + application/xml Je pense pas que ça soit une bonne idée de laisser de mime-type sur les fichiers, car svn (1.6?) le considère comme un binaire? http://svn.haxx.se/users/archive-2008-03/1068.shtml on devrait plutot utiliser text/xml (et encore si c'est vraiment nécessaire car moi je vois pas la plus-value ?) En tout cas faut pas que les poms soient des fichiers binaires (y'a que sous eclipse que c'est possible :D) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

Proposition de fonctionnement avec un plugin maven
by Benjamin POUSSIN April 3, 2012

April 3, 2012

Salut, J'ai un peu réfléchi a l'utilisation possible pour cette lib. Voici mes propositions: chaque lib est un module du projet. On indique: - l'url des fichiers à récuperer - si l'on peut utiliser ces url directement dans l'appli final On met ces libs en dépendance de son projet On configure le plugin maven-nuiton-js pour indiquer: - si l'on souhaite utiliser les fichiers distant pour ceux qui le support - si on veut utiliser son propre serveur distant en plus pour les libs qui n'ont pas de serveur propre (déploiement de nuiton-js sur un serveur) - si on veut utiliser son propre serveur distant pour toutes les libs Le plugin genere un script js (<nomprojet-nuiton.js> qui est le seul a devoir être inclus dans son projet. Ce script load comme demander toutes les librairies, si la librairie distante n'est pas recuperable (ex:reseau coupé), alors le fichier js de la dépendance est utiliser. Le chargement des librairies se fait en parallele en respectant les dépendance si besoin. Les scripts spécifiques à l'application peuvent être elle aussi en module ou bien directement dans le projet. Dans ce dernier cas, la liste est indique via la fonction genere par le plugin. <script src="monapp-jslib.js"/> <script> monapp_nuiton.load([ "fichier1.js", "fichier2.js" ]); </script> pour faire tout ca on peut s'appuyer/s'inspirer de head.js Un peu plus d'explication technique: Le fichier monapp-jslib.js, sera sans doute inclus dans le fichier de layout (ex: sitemesh ou tiles) et donc importé pour toutes les pages. Ce n'est pas dérangeant car non pénalisant pour le temps de chargement de la page (le chargement des scripts se faisant en tache de fond) Une fois la première page visité, tous les scripts seront dans le cache du navigateur et donc ne seront plus ramené. Si des sites autres que le serveur qui héberge l'application est utilisé cela peut-etre un plus car un serveur et les clients web ne permettent pas d'ouvrir plus de 3 ou 4 connexions pour un couple (ip client/ip serveur). De cette façon si beaucoup de script js et css sont à ramener ils le seront réellement en parallèle car sur plusieurs serveurs (et comme toujours au pire si le site distant ne répond pas, le js sera pris sur le même serveur que l'application) Voilà, les avantages que j'y trouve: - un seul import d'un seul fichier js (pas de js multiple et css) - gestion des dépendances entre lib js (ex: le script d'autocomplete est en jquery, il me faut donc aussi jquery) - chargement en parallèle des scripts et css - gestion des licences (modules maven pour chaque lib) - si utilisation de serveurs tiers pour la récupération de js et qu'il y a des proxies/caches (squid) en place, le scripts sera surement déjà dans le cache grâce à une autre application. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

2 1

Packaging jar ou war ?
by Eric Chatellier April 2, 2012

April 2, 2012

Bonjour, J'ai créé le projet nuiton-js suite à la réunion qui a instauré sa création. J'ai pour l'instant ajouter les tickets pour l'ajout des libs jquery et bootstrap. Il me semble que durant la réunion, on avait statué sur la packaging war pour l'assemblage automatique des overlays. Cependant, pour bootstrap par exemple, il devrait être possible de l'utiliser dans un maven site et il serait plus judicieux que cela soit un jar seulement. Comme on peut le voir ici, les overlays avec des jar sont possible: http://www.chorem.org/projects/pollen/repository/revisions/3089/entry/trunk… -- Éric Chatellier

3 3