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