Génération d'un report pour ApplicationConfig
Hello, En parlant de la documentation de Pollen, m'est venue une idée de générer un rapport Maven pour ApplicationConfig qui donne toutes les options possibles pour une implantation d'application config. Il faudrait pour ce faire ajouter la notion de provider d'option (une classe qui donne juste le fqn de l'énum où y'a les options et le type de configuration). Ce provider est chargé via un ServiceLoader, donc rien à faire pour client (ici le plugin maven). Ensuite pour chaque configuration (wikity, topia, ..., application finale), on affiche un beau tableau où y'a toutes les optiosn avec leur description, valuer par defaut et type. Tout ça est facile à faire et peu couteux et ça serait bien pratique pour ne pas l'écrire à la main et surtout c'est générable (donc ça suivra bien les évolutions des configurations). Avant de mettre les jolies tableaux on pourrait aussi avoir en introduction un paragraphe qui explique comment fonctionne applicationConfig (la logique des configuration surchargé), où positionner son fichier de configuration (/etc, home, dir,...) Je vote +1 pour faire ça. Je vais tenter ça ce week-end je pense. Si y'a d'autres idées d'ici là je suis preneur tony.
On 27/04/2012 12:00, Tony Chemit wrote:
Hello,
En parlant de la documentation de Pollen, m'est venue une idée de générer un rapport Maven pour ApplicationConfig qui donne toutes les options possibles pour une implantation d'application config.
Il faudrait pour ce faire ajouter la notion de provider d'option (une classe qui donne juste le fqn de l'énum où y'a les options et le type de configuration).
Ce provider est chargé via un ServiceLoader, donc rien à faire pour client (ici le plugin maven).
Ensuite pour chaque configuration (wikity, topia, ..., application finale), on affiche un beau tableau où y'a toutes les optiosn avec leur description, valuer par defaut et type.
Tout ça est facile à faire et peu couteux et ça serait bien pratique pour ne pas l'écrire à la main et surtout c'est générable (donc ça suivra bien les évolutions des configurations).
Avant de mettre les jolies tableaux on pourrait aussi avoir en introduction un paragraphe qui explique comment fonctionne applicationConfig (la logique des configuration surchargé), où positionner son fichier de configuration (/etc, home, dir,...)
Je vote +1 pour faire ça. Je vais tenter ça ce week-end je pense.
Si y'a d'autres idées d'ici là je suis preneur Très bonne idée, je vote +1 aussi. Cette page apparaîtra seulement dans les rapports maven par contre ? Peut-être le rajouter manuellement sur une page d'installation pour les applications finales qui le nécessite.
Autre idée indépendante : Je pensais également au README.txt, a priori il devrait comporter tout ce qu'une page d'installation devrait avoir, non ? Ce serait peut-être intéressant de pouvoir le récupérer et/ou le synchroniser avec la documentation maven.
D'une façon plus générale, je réfléchis à comment générer des choses à partir du code ou l'inverse mais c'est difficile. Ça m'intéresse si tu te penches là-dessus. Ton exemple est un bon problème de départ, suffisamment petit pour pouvoir s'y pencher. L'idée que j'avais était d'appliquer ça aux modèles CSV, pour pouvoir pondre automatiquement la doc colonnes/formats attendus/séparateur etc. Donc je dis bonne démarche, +1. Le 27/04/2012 12:00, Tony Chemit a écrit :
Si y'a d'autres idées d'ici là je suis preneur
-- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
On Fri, 27 Apr 2012 12:34:01 +0200 Brendan Le Ny <bleny@codelutin.com> wrote:
D'une façon plus générale, je réfléchis à comment générer des choses à partir du code ou l'inverse mais c'est difficile. Ça m'intéresse si tu te penches là-dessus. Ton exemple est un bon problème de départ, suffisamment petit pour pouvoir s'y pencher.
L'idée que j'avais était d'appliquer ça aux modèles CSV, pour pouvoir pondre automatiquement la doc colonnes/formats attendus/séparateur etc.
Donc je dis bonne démarche, +1.
Au niveau de Applicationconfig c'est assez facile en fait car on a les OptionDef qui caractérisent des options donc pas grand chose à faire. Sur les imports, on pourrait avoir : - annotations - javadoc doclets Je pense créer un nouveau moduel dans nuiton-utils pour faire ça car c'est le meilleur endroit pour faire ça. Pour le choix du nom du module : - nuiton-utils-maven-plugin - nuiton-utils-report-plugin Je pencherais plutôt pour la second solution : c'est bien des report qu'on veut faire ici et rien d'autre. Qui dit mieux?
Le 27/04/2012 12:00, Tony Chemit a écrit :
Si y'a d'autres idées d'ici là je suis preneur
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Fri, 27 Apr 2012 12:44:09 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Pour le choix du nom du module : - nuiton-utils-maven-plugin - nuiton-utils-report-plugin nuiton-utils-maven-report-plugin plutôt...
Je pencherais plutôt pour la second solution : c'est bien des report qu'on veut faire ici et rien d'autre.
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Fri, 27 Apr 2012 12:44:09 +0200 Tony Chemit <chemit@codelutin.com> wrote: ...
Au niveau de Applicationconfig c'est assez facile en fait car on a les OptionDef qui caractérisent des options donc pas grand chose à faire.
AppConfig a toujours été fait pour qu'on est pas cette doc a écrire. Mais pour l'instant la seule doc générée est celle que l'on peut faire facilement via par exemple un --help sur la ligne de commande. La seule crainte que j'ai avec la notion de service provider, est que du coup le développeur de l'application finale ne puisse pas choisir les enums a intégrer pour son programme, toutes celles qui seront trouvées seront utilisées. Et en même temps je ne vois pas de cas, ou on utiliserait une librairies avec AppConfig dont on ne souhaiterait pas pouvoir charger les options. Si quelqu'un voit des cas l'autre solution serait que le développeur mette en place une action --help-html (le développeur utilise une méthode qui génère tout le html de AppConfig). Et le plugin pour générer la doc lancerait juste l'application avec l'option --help-html et récupère la sortie. Donc dans ce cas on est sur que le développeur à pu choisir les Enum qu'il voulait et ne pas prendre celle qu'il ne voulait pas. Mais je préfère ta solution tant que personne ne trouve de cas, ou un développeur ne voudrait pas de toutes les options. Car justement, il n'aura plus à se préoccuper à penser à inclure les options de telle ou telle lib. Elle seront incluses automatiquement lorsqu'il aura mis une lib en dépendance. (si j'ai bien tout compris ? :))
Sur les imports, on pourrait avoir :
- annotations - javadoc doclets
Là, je ne comprend rien ? je ne vois pas de quoi tu parles :(
Je pense créer un nouveau moduel dans nuiton-utils pour faire ça car c'est le meilleur endroit pour faire ça.
Pour le choix du nom du module : - nuiton-utils-maven-plugin - nuiton-utils-report-plugin
Je pencherais plutôt pour la second solution : c'est bien des report qu'on veut faire ici et rien d'autre.
le 2eme aussi -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Sat, 28 Apr 2012 12:05:14 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Fri, 27 Apr 2012 12:44:09 +0200 Tony Chemit <chemit@codelutin.com> wrote:
...
Au niveau de Applicationconfig c'est assez facile en fait car on a les OptionDef qui caractérisent des options donc pas grand chose à faire.
AppConfig a toujours été fait pour qu'on est pas cette doc a écrire. Mais pour l'instant la seule doc générée est celle que l'on peut faire facilement via par exemple un --help sur la ligne de commande. Oui moi je pense aux applications web et autre.
Il faut écrire à la main de help, on l'a qu'en console et donc pas très sexy et pratique. Le fait de l'avoir généré sur le site pour mmoi c'est tout bonus.
La seule crainte que j'ai avec la notion de service provider, est que du coup le développeur de l'application finale ne puisse pas choisir les enums a intégrer pour son programme, toutes celles qui seront trouvées seront utilisées. Et en même temps je ne vois pas de cas, ou on utiliserait une librairies avec AppConfig dont on ne souhaiterait pas pouvoir charger les options.
Pas de soucis, on peut ajouter une notion de filtre sur les providers à inserer dans la doc (include/exclude). On récuèpre dans le report tous les providers puis ensuite on ne traite que ceux voulus (ou tous si pas de modif de conf).
Si quelqu'un voit des cas l'autre solution serait que le développeur mette en place une action --help-html (le développeur utilise une méthode qui génère tout le html de AppConfig). Et le plugin pour générer la doc lancerait juste l'application avec l'option --help-html et récupère la sortie. Donc dans ce cas on est sur que le développeur à pu choisir les Enum qu'il voulait et ne pas prendre celle qu'il ne voulait pas.
ça ne marche que pour les clients lourds. Je préfère la solution d'une page générée dans le site directement.
Mais je préfère ta solution tant que personne ne trouve de cas, ou un développeur ne voudrait pas de toutes les options. Car justement, il n'aura plus à se préoccuper à penser à inclure les options de telle ou telle lib. Elle seront incluses automatiquement lorsqu'il aura mis une lib en dépendance. (si j'ai bien tout compris ? :))
Yes, je pars la-dessus et on avisera si besoin ;)
Sur les imports, on pourrait avoir :
- annotations - javadoc doclets
Là, je ne comprend rien ? je ne vois pas de quoi tu parles :(
impor-csv et autres... Autre sujet. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
participants (4)
-
Benjamin POUSSIN -
Brendan Le Ny -
Florian Desbois -
Tony Chemit