Nouveau module pour Application config ?
Hello, Je pense qu'il serait bien de créer un nouveau module pour y mettre tout ce qui touche à ApplicationConfig (et surtout pouvoir éclater la classe ApplicationConfig car là une classe de plus de 2700 lignes, je dis bof :(). Pour le package je voyais org.nuiton.util.config, histoire de ne pas avoir de collision avec la classe dépréciée qu'on laisserait dans l'ancien nuiton-utils Qu'en pensez-vous ? tony.
Salut ! Ca me parait pas une mauvaise idée. Splitter la classe serait une bonne chose (avec ou sans changement de module). Passer dans un module propre, ça peut être aussi intéressant, mais est-ce vraiment utile ? A part une meilleure visibilité (ce qui n'est pas rien déjà ;), qu'y a-t-il à y gagner ? Je reste mitigé :\ Il ne faudrait pas non plus ouvrir une brèche vers le "tout-en-minimodule", le simple fait de revoir le packaging suffisant dejà à y voir plus clair, non ? Le 2013-01-04 10:09, Tony Chemit a écrit :
Hello,
Je pense qu'il serait bien de créer un nouveau module pour y mettre tout ce qui touche à ApplicationConfig (et surtout pouvoir éclater la classe ApplicationConfig car là une classe de plus de 2700 lignes, je dis bof :().
Pour le package je voyais org.nuiton.util.config, histoire de ne pas avoir de collision avec la classe dépréciée qu'on laisserait dans l'ancien nuiton-utils
Qu'en pensez-vous ?
tony. _______________________________________________ Nuiton-utils-devel mailing list Nuiton-utils-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/nuiton-utils-devel
-- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
On Fri, 04 Jan 2013 15:08:27 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut !
Ca me parait pas une mauvaise idée. Splitter la classe serait une bonne chose (avec ou sans changement de module).
Passer dans un module propre, ça peut être aussi intéressant, mais est-ce vraiment utile ? A part une meilleure visibilité (ce qui n'est pas rien déjà ;), qu'y a-t-il à y gagner ?
Je reste mitigé :\ Il ne faudrait pas non plus ouvrir une brèche vers le "tout-en-minimodule", le simple fait de revoir le packaging suffisant dejà à y voir plus clair, non ?
pour moi non, va voir nuiton-profiling : y'a une classe dedans, donc pour la brèche c'est déjà fait... Surtout ce que j'y vois c'est avoir un artifact qui a un but, parce que pour moi ApplicationConfig (nuiton-config) et bien délimité et ne devrait pas être mélangé avec nuiton-utils qui est un foure tout de classes plus au moin pas du tout utiles :( ApplicationConfig est bien, je trouve dommage que ça soit au milieu d'un bordel sans nom :( Et c'est plus juste qu'une classe utilitaire vu qu'il a y'a d'autre truc autour. Avoir son propre module permettrait d'améliorer sa visibilité et pouvoir plus le mettre en valeur, perso je veux utiliser ApplicationConfig mais pas nuiton-utils... et idem je voudrais bien sortir d'autres modules (nuiton-beans, nuiton-converter, ...)
Le 2013-01-04 10:09, Tony Chemit a écrit :
Hello,
Je pense qu'il serait bien de créer un nouveau module pour y mettre tout ce qui touche à ApplicationConfig (et surtout pouvoir éclater la classe ApplicationConfig car là une classe de plus de 2700 lignes, je dis bof :().
Pour le package je voyais org.nuiton.util.config, histoire de ne pas avoir de collision avec la classe dépréciée qu'on laisserait dans l'ancien nuiton-utils
Qu'en pensez-vous ?
tony. _______________________________________________ Nuiton-utils-devel mailing list Nuiton-utils-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/nuiton-utils-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 2013-01-04 15:18, Tony Chemit a écrit :
On Fri, 04 Jan 2013 15:08:27 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut !
Ca me parait pas une mauvaise idée. Splitter la classe serait une bonne chose (avec ou sans changement de module).
Passer dans un module propre, ça peut être aussi intéressant, mais est-ce vraiment utile ? A part une meilleure visibilité (ce qui n'est pas rien déjà ;), qu'y a-t-il à y gagner ?
Je reste mitigé :\ Il ne faudrait pas non plus ouvrir une brèche vers le "tout-en-minimodule", le simple fait de revoir le packaging suffisant dejà à y voir plus clair, non ?
pour moi non, va voir nuiton-profiling : y'a une classe dedans, donc pour la brèche c'est déjà fait...
Eurk. Mais c'est cependant pas une raison de la renforcer à mon gout ;)
Surtout ce que j'y vois c'est avoir un artifact qui a un but, parce que pour moi ApplicationConfig (nuiton-config) est bien délimité et ne devrait pas être mélangé avec nuiton-utils qui est un foure tout de classes plus au moin pas du tout utiles :(
Là dessus, je te rejoins. Je serais meme partisan de faire un brin de ménage et d'enlever ce qui n'est pas utile, et de tenter de reverser à des librairies (comme commons?) certaines choses (comme StringUtil?). Cela ferait participer aux communautés, et éviterait de réinventer trop souvent la roue et multiplier des dépendances dans les projets :p
ApplicationConfig est bien, je trouve dommage que ça soit au milieu d'un bordel sans nom :( Et c'est plus juste qu'une classe utilitaire vu qu'il a y'a d'autre truc autour.
Avoir son propre module permettrait d'améliorer sa visibilité et pouvoir plus le mettre en valeur, perso je veux utiliser ApplicationConfig mais pas nuiton-utils... et idem je voudrais bien sortir d'autres modules (nuiton-beans, nuiton-converter, ...)
Je suis d'accord, ça me parait même malin :) -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28
On 01/04/2013 03:39 PM, Yannick Martel wrote:
Le 2013-01-04 15:18, Tony Chemit a écrit :
On Fri, 04 Jan 2013 15:08:27 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut !
Ca me parait pas une mauvaise idée. Splitter la classe serait une bonne chose (avec ou sans changement de module).
Passer dans un module propre, ça peut être aussi intéressant, mais est-ce vraiment utile ? A part une meilleure visibilité (ce qui n'est pas rien déjà ;), qu'y a-t-il à y gagner ?
Je reste mitigé :\ Il ne faudrait pas non plus ouvrir une brèche vers le "tout-en-minimodule", le simple fait de revoir le packaging suffisant dejà à y voir plus clair, non ?
pour moi non, va voir nuiton-profiling : y'a une classe dedans, donc pour la brèche c'est déjà fait...
Eurk. Mais c'est cependant pas une raison de la renforcer à mon gout ;)
Mon avis, c'est que je suis pas contre les petit modules bien spécialisés, ça permet de tirer uniquement ce qu'on veut et c'est bien de pouvoir être fin quand un veut produire un petit exécutable (jtimer, appli embarquée ou android). Par contre, ce qui est chiant, c'est que dans 80% des projets, en fait t'as besoin de tout et du coup ça fait des dependencyManagement de 3 kilomètres :-(. Alors le bon compromis, il me semble, c'est d'avoir plusieurs modules tout petit mais aussi d'autres modules à côté genre "-bundle" qui te permet de tirer 3/4/5 autres modules en transitifs pour pas surcharger ton pom projet.
Surtout ce que j'y vois c'est avoir un artifact qui a un but, parce que pour moi ApplicationConfig (nuiton-config) est bien délimité et ne devrait pas être mélangé avec nuiton-utils qui est un foure tout de classes plus au moin pas du tout utiles :(
Là dessus, je te rejoins. Je serais meme partisan de faire un brin de ménage et d'enlever ce qui n'est pas utile, et de tenter de reverser à des librairies (comme commons?) certaines choses (comme StringUtil?). Cela ferait participer aux communautés, et éviterait de réinventer trop souvent la roue et multiplier des dépendances dans les projets :p
C'est ce qu'on avait décidé le 14/10/2011, dans le CR : « Nuiton-Utils et commons-lang [...] Par contre, ce serait bien de proposer nos méthodes à Commons. » Mes deux centimes (qui n'en valent plus que 1,96 vu l'inflation 2012).
On Fri, 04 Jan 2013 15:39:35 +0100 Yannick Martel <martel@codelutin.com> wrote:
pour moi non, va voir nuiton-profiling : y'a une classe dedans, donc pour la brèche c'est déjà fait...
Eurk. Mais c'est cependant pas une raison de la renforcer à mon gout ;)
Je pense qu'il ne faut pas confondre un module avec une classe et un module avec une classe :) qui tire le monde entier. Et c'est un peu le cas de nuiton-profiling qui a besoin de aspectj (bon j'ai vu pire aussi :)). Mais surtout clairement nuiton-profiling n'a pas a rester en dependance du projet lorsque le projet est en production alors que nuiton-utils si :) Pour moi, il faut bien un module pour nuiton-profiling meme s'il n'y a qu'une classe. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
participants (4)
-
Benjamin POUSSIN -
Brendan Le Ny -
Tony Chemit -
Yannick Martel