Nuiton utils prend du poids
Salut, Je constate simplement que nuiton-utils a beaucoup de dépendences, et cela ne me parait pas philosophiquement compatible avec une lib "utils" (au même titre que commons-lang, guava...). À l'heure actuelle, nuiton-utils fait 298ko + 4,6Mo de dep (dont guava, 2,2Mo à lui tout seul). Tout ca pour dire, que dans dans jtimer par exemple, la taille acceptable de l'application ne pouvant pas raisonablement dépasser 10Mo, j'aime bien ApplicationConfig, mais la taille de la lib devient un gros frein. Il y a bien l'astuce d'exclusion, mais on ne peux pas être sur qu'un un moment, une librairie exclue deviendra utilisée. Librement. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On Fri, 12 Jul 2013 11:04:48 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Salut,
Je constate simplement que nuiton-utils a beaucoup de dépendences, et cela ne me parait pas philosophiquement compatible avec une lib "utils" (au même titre que commons-lang, guava...).
C'est pourquoi je me bats depuis longtemps pour qu'on abandonne ce projet au profit de contribution dans commons-* et guava. La seule chose intéressante serait d'avoir des micro-lib qui font un besoin précis : nuiton-config nuiton-csv nuiton-validator ... nuiton-utils pour moi j'ai juste une lib de feignant et d'anti-communautaire java. Soit dit en passant, y'a pas tant de déps sur nuiton-utils, non ? http://maven-site.nuiton.org/nuiton-utils/nuiton-utils/dependencies.html Y'a que des libs commons-* + guava
À l'heure actuelle, nuiton-utils fait 298ko + 4,6Mo de dep (dont guava, 2,2Mo à lui tout seul).
A bat guava ! vive nuiton! (sarcasme of course)
Tout ca pour dire, que dans dans jtimer par exemple, la taille acceptable de l'application ne pouvant pas raisonablement dépasser 10Mo, j'aime bien ApplicationConfig, mais la taille de la lib devient un gros frein.
D'où sort ce chiffre magique de 10Mo? en plus de raison ? merde je saivais pas qu'on pouvait mettre de telles notions sur une taille on parle de Mo ou Mb ? je suis perdu.
Il y a bien l'astuce d'exclusion, mais on ne peux pas être sur qu'un un moment, une librairie exclue deviendra utilisée.
Bah si (enfin je pense, à vérifier) avec l'analyse des dépendances fatalement tu ne devrais pas pouvoir faire une release si y'a une dep pas bien mise en scope compile ;) en même temps, quand on fait des Class.forName("xxx") rien n'est moins sûr :D tony.
On Fri, 12 Jul 2013 11:41:15 +0200 Tony Chemit <chemit@codelutin.com> wrote:
On Fri, 12 Jul 2013 11:04:48 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Salut,
Je constate simplement que nuiton-utils a beaucoup de dépendences, et cela ne me parait pas philosophiquement compatible avec une lib "utils" (au même titre que commons-lang, guava...).
Pour guava utilisé dans BeanUtil pour l'API Predicate, pas évident de faire autrement ... Par contre ApplicationUpdater utilise commons-vfs2 qui lui est plus atypique, il pourrait peut-être passer en module ?
On Fri, 12 Jul 2013 11:04:48 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Salut,
Je constate simplement que nuiton-utils a beaucoup de dépendences, et cela ne me parait pas philosophiquement compatible avec une lib "utils" (au même titre que commons-lang, guava...).
À l'heure actuelle, nuiton-utils fait 298ko + 4,6Mo de dep (dont guava, 2,2Mo à lui tout seul).
Je suis d'accord que la taille de nuiton-utils doit rester petit et les dépendances quasi inexistante. Les choses dont on se sert dans tous les projets devrait etre minimaliste (taille et dépendance): - config - updater - csv - validator Une première étape a été de faire des modules, mais peut-etre devrait-il devenir des projets ? Et peut-être y a-t-il d'autres choses à passer en module puis projet voir à déprécier (je pense a de vielle chose qui ne fonctionne pas :(). Pas mal de dépendance de nuiton-utils viennent a cause d'api dépréciée (en module maintenant), donc peut-être serait-il temps de passer une version majeur pour supprimer tout ce qui est déprécié ? en même temps que de créer les projets en place de module. donc quelques propositions d'actions à faire: Passer en projet: - config - updater - csv - validator Creer les modules: - decorator (qui tire jxpath qui tire guava) - converter Savoir ce qu'on se permet comme dépendance (je dirais) - commons.lang3 - commons.logging S'il y en a d'autre pour une classe ou un package, il faut qu'il ait son module (voir projet) Les dépendances interdites (dans nuiton-utils): - commons.beanutils - commons.io - commons.vfs2 (seulement utilise par AppUpdater qui est deprecié) - commons.collections (dans quelques cas, on peut facilement s'en passer (ex: AppConfig)) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 17 Jul 2013 19:22:09 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Fri, 12 Jul 2013 11:04:48 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Salut,
Je constate simplement que nuiton-utils a beaucoup de dépendences, et cela ne me parait pas philosophiquement compatible avec une lib "utils" (au même titre que commons-lang, guava...).
À l'heure actuelle, nuiton-utils fait 298ko + 4,6Mo de dep (dont guava, 2,2Mo à lui tout seul).
Je suis d'accord que la taille de nuiton-utils doit rester petit et les dépendances quasi inexistante.
Les choses dont on se sert dans tous les projets devrait etre minimaliste (taille et dépendance): - config - updater - csv - validator
Une première étape a été de faire des modules, mais peut-etre devrait-il devenir des projets ?
Et peut-être y a-t-il d'autres choses à passer en module puis projet voir à déprécier (je pense a de vielle chose qui ne fonctionne pas :().
Pas mal de dépendance de nuiton-utils viennent a cause d'api dépréciée (en module maintenant), donc peut-être serait-il temps de passer une version majeur pour supprimer tout ce qui est déprécié ? en même temps que de créer les projets en place de module.
donc quelques propositions d'actions à faire:
Passer en projet: - config - updater - csv - validator
ça me parrait une excellente idée, je veux bien me charger de cette tâche; par contre du coup on supprimera du package de *util* : org.nuiton.util.config deviendra *org.nuiton.config* Il est vrai que très souvent on release les n modules alors qu'on a uniquement travaillé sur un seul des modules, c'est môches; plusieurs fois je n'ai uniquement releasé que le module incriminé mais c'est compliqué et ensuite on perd la synchro sur les versions, donc autant rendre tout autonome.
Creer les modules: - decorator (qui tire jxpath qui tire guava) - converter +10
Savoir ce qu'on se permet comme dépendance (je dirais) - commons.lang3 - commons.logging j'aurais laissé commons-collections sinon je serais aussi pour supprimer commons-lnag3 (je vois pas en fait pourquoi gardé l'un et pas l'autre)
S'il y en a d'autre pour une classe ou un package, il faut qu'il ait son module (voir projet)
Les dépendances interdites (dans nuiton-utils): - commons.beanutils - commons.io - commons.vfs2 (seulement utilise par AppUpdater qui est deprecié) - commons.collections (dans quelques cas, on peut facilement s'en passer (ex: AppConfig))
Je propose donc o en 2.7 on déprécie tout (et on créer les projets + modules annexes) o les nouveaux projets seront releasés en 1.0 o en 3.0 on vire tout le code déprécié Si personne n'est contre je commence hier :D -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Thu, 18 Jul 2013 10:30:57 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Je propose donc
o en 2.7 on déprécie tout (et on créer les projets + modules annexes) o les nouveaux projets seront releasés en 1.0 o en 3.0 on vire tout le code déprécié
Au final les nouveaux projets, on va les commencer en 2.7 (ou 3.0?) pour plusieurs raisons: o conserver l'historique des versions des since o ne pas avoir de collisions avec les anciens artifacts puisque les coordonnées vont rester les même... je modifie ce que j'ai déjà fait dans se sens bon week-end, tony.
On Wed, 17 Jul 2013 19:22:09 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Creer les modules: - decorator (qui tire jxpath qui tire guava)
j'ai crée un projet (je vois plus du coup l'intérêt d'un module si on essaye de virer les autres)
- converter
rien fait pour le moment, mais ayant repassé nuiton-utils en simple projet (sans multi-module), ça m'embète un peu de faire ça, autant alors crée un autre projet. ?
Savoir ce qu'on se permet comme dépendance (je dirais) - commons.lang3 - commons.logging
S'il y en a d'autre pour une classe ou un package, il faut qu'il ait son module (voir projet)
Les dépendances interdites (dans nuiton-utils): - commons.beanutils
utiliser dans le package o.n.u.bean
- commons.io - commons.vfs2 (seulement utilise par AppUpdater qui est deprecié) - commons.collections (dans quelques cas, on peut facilement s'en passer (ex: AppConfig))
utiliser dans le package o.n.u.bean + guava, je peux changer l'api Precidate pour celle de commons, je serais plutot d'avis de créer un nouveau projet alors si on veut avoir une philosophie de nuiton-utils tout mini... -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 12/07/2013 11:04, Eric Chatellier a écrit :
Salut,
Je constate simplement que nuiton-utils a beaucoup de dépendences, et cela ne me parait pas philosophiquement compatible avec une lib "utils" (au même titre que commons-lang, guava...).
À l'heure actuelle, nuiton-utils fait 298ko + 4,6Mo de dep (dont guava, 2,2Mo à lui tout seul). Petit retour (post mortem) sur la réorganisation en module. nuiton-utils a perdu du poids : 268k mais pas de dépendance (toujours 4,6Mo)
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
participants (4)
-
Arnaud Thimel -
Benjamin POUSSIN -
Eric Chatellier -
Tony Chemit