Expérimentation de XWiki
David Andriana
la boîte où je travaille.
L'expérience montre que c'est loin d'être un produit fini, cependant :
1. il est en Java (il tourne sous Jetty)
2. c'est à ma connaissance le seul wiki open source en Java
3. l'indexation existe, grâce à Lucene
4. il est extensible
5. il utilise sa propre base de données (hsqldb il me semble)
6. il permet le scripting dans les pages avec Velocity, ce qui le rend
très « puissant », entendre attrayant pour un technicien
Mais :
D1. il est buggé de partout
D2. la Beta 2 (9/01) n'est franchement pas mieux : j'ai même dû la
désinstaller
D3. le scripting (Velocity) risque de rendre les pages totalement
inmaintenables
D4. il semble très mal foutu, notamment pour les skins
Maintenant sur le plan organisationnel :
O1. un wiki plutôt qu'un forum ? Oui. Pour 10 personnes peu habituées
aux forums, il vaut mieux tracer et capitaliser, que discuter.
O2. un wiki plutôt qu'un blog ? Oui. Pareil, pour le public visé, il
vaut mieux tracer et capitaliser, qu'espérer avoir des posts
quotidiens.
O3. installation avec l'aval du management ? Pas d'aval officiel. C'est
une « expérimentation interne ». La position officielle, c'est qu'un
outil de travail collaboratif est *développé en interne*, et verra
le jour en novembre 2007, autant dire quand tout le monde sera déjà
parti pour monter sa boîte.
O4. aval de la direction ? Certainement pas un aval officiel, mais un
certain capital sympathie -- le capital sympathie du nouvel
arrivant.
O5. aval des administrateurs système et réseau ? Ben... non.
Installation sur mon poste, avec tous les inconvénients que cela
entraîne.
O6. était-il prioritaite d'installer un tel outil ? Oui, pour plusieurs
raisons :
- marre des discussions de couloirs où on échange <n> fois les mêmes
infos (techniques) entre les personnes A et B, puis entre A et C,
puis entre B et C... tout simplement parce qu'il n'y a pas de
« Common Knowledge » sur le sujet (B ne sait pas que A sait que C
est déjà au courant...)
- la solution à cela serait de faire des réunions pour tout, mais ça
serait coûteux, et ça ne résoudrait même pas le problème quand
vient une quatrième personne D... et que A informe D, puis B ne
sachant pas que D est au courant, demande alors à C d'informer D,
mais D en fait part à A et... bref. Vous voyez l'idée. Du temps
perdu, pour une capitalisation nulle (je rappelle que 6 mois plus
tard, D s'en va pour monter sa boîte, et doit être remplacé par
E).
- je ne parle même pas de l'absence de documentation à jour
- il faut jouer sur le capital sympathie quand il est sûr, donc au
début. J'ai installé l'outil un mois jour pour jour après mon
arrivée.
Je précise que la demande « officielle » est d'avoir un outil de travail
collaboratif AU MOINS aussi puissant que Confluence (j'attends de voir
l'outil maison face à ce cahier des charges !). Et en attendant, on fait
au mieux.
Question : avez-vous des expériences similaires ?
Sondage : utilisez-vous une plateforme de capitalisation informelle là
où vous bossez ?
Liens :
- produit XWiki : http://www.xwiki.org/
- plateforme XWiki en ligne : http://www.xwiki.com/
--
David
Benoit LAFFITTE
J'ai installé récemment XWiki Beta 1 pour la cellule d'architectes dans
la boîte où je travaille.
L'expérience montre que c'est loin d'être un produit fini, cependant :
1. il est en Java (il tourne sous Jetty)
2. c'est à ma connaissance le seul wiki open source en Java
Et non il y a aussi JSPWiki, plus modeste mais avec peu de bug de ce que j'ai pu en voir
http://jspwiki.org/
Christophe Brugne
On 1/12/07, David Andriana < david.a...@free.fr> wrote:
J'ai installé récemment XWiki Beta 1 pour la cellule d'architectes dans
la boîte où je travaille.
L'expérience montre que c'est loin d'être un produit fini, cependant :
1. il est en Java (il tourne sous Jetty)
2. c'est à ma connaissance le seul wiki open source en Java
Et non il y a aussi JSPWiki, plus modeste mais avec peu de bug de ce que j'ai pu en voir
http://jspwiki.org/
Plus une persistance des données en fichiers texte : KISS quoi !
--
Christophe Brugne
Pierre Kypréos
Tout pareil JSPWiki. Le détail des fonctionnalité comparé à XWiki :
http://www.wikimatrix.org/compare/JSPWiki+XWiki
Pierre
David Andriana
> > Et non il y a aussi JSPWiki, plus modeste mais avec peu de bug de ce que
> > j'ai pu en voir
> > http://jspwiki.org/
Rhâââ, il y en avait donc un autre !
Bien. Que je vous fasse part d'un tout petit problème : une fois qu'on a
goûté au scripting avec Velocity, et aux objets de XWiki, c'est
difficile de s'en passer (oui, oui, je sais, les pages ne seront pas
maintenables).
Il faudrait que j'essaie le scripting TCL dans JSPWiki.
> > Itou, quelques bugs mais pas la sensation d'un produit en beta pour
> JSPWIki.
À tester, donc...
> Plus une persistance des données en fichiers texte : KISS quoi !
La base par défaut dans XWiki est hsqldb, donc on se retrouve pour les
backups avec de bêtes fichiers. C'est relativement simple aussi.
--
David
Pierre Kypréos
La base par défaut dans XWiki est hsqldb, donc on se retrouve pour les
backups avec de bêtes fichiers. C'est relativement simple aussi.
Il n'y a pas que la problématique de backup.
Nous sommes d'accord avec Christophe que les fichiers soient au format text pour pouvoir aisément faire une migration sans perte d'information...
Benoit LAFFITTE
Pour info sur HSQLDB, les fichiers binaires en question sont des commandes INSERT gzzipper , et de memoire leslob sont en base 64....
David Andriana
> Nous sommes d'accord avec Christophe que les fichiers soient au format text
> pour pouvoir aisément faire une migration sans perte d'information...
Une migration de XWiki vers un autre système ne serait qu'une migration
de données, et ne serait pas très intéressante.
Dans XWiki, il y a un système de scripting, et surtout une API
propriétaire d'accès aux objets internes, propriétaires également.
Et on peut évidemment rajouter l'accès au Système d'Information.
Ainsi je pourrais avoir dans mon wiki une page à jour sur mon équipe,
avec les informations récupérées auprès des services administratifs du
SI.
XWiki est loin d'implémenter une bonne séparation entre articles
(informations) et commandes (traitements, scripting, etc.), mais il y a
déjà du potentiel.
--
David
David Andriana
> > Itou, quelques bugs mais pas la sensation d'un produit en beta pour
> JSPWIki.
> Plus une persistance des données en fichiers texte : KISS quoi !
J'ai un gros souci dans la mise en oeuvre de XWiki Beta 1 :
l'interpréteur WYSIWYG est totalement buggé. Il arrive même à m'effacer
des pages que j'ai codées bas niveau.
Cependant, d'après wikimatrix.org, ni SnipSnap ni JSPWiki ne proposent
l'édition WYSIWYG en standard.
Or c'est le seul point qui bloque l'adoption...
Je serais même prêt à passer à PHP du moment qu'il y a du WYSIWYG, c'est
dire.
Une lumière, quelqu'un ?
--
David
Christophe Brugne
Selon Christophe Brugne <chris...@brugne.fr.st>:
> > Itou, quelques bugs mais pas la sensation d'un produit en beta pour
> JSPWIki.
> Plus une persistance des données en fichiers texte : KISS quoi !
J'ai un gros souci dans la mise en oeuvre de XWiki Beta 1 :
l'interpréteur WYSIWYG est totalement buggé. Il arrive même à m'effacer
des pages que j'ai codées bas niveau.
Cependant, d'après wikimatrix.org, ni SnipSnap ni JSPWiki ne proposent
l'édition WYSIWYG en standard.
Ce n'est pas un problème, il suffit d'installer l'extension.
Or c'est le seul point qui bloque l'adoption...
Je serais même prêt à passer à PHP du moment qu'il y a du WYSIWYG, c'est
dire.
Une lumière, quelqu'un ?
--
David
--
Christophe Brugne
chris...@brugne.fr.st
David Andriana
> J'ai un gros souci dans la mise en oeuvre de XWiki Beta 1 :
> l'interpréteur WYSIWYG est totalement buggé.
Finalement, en faisant une clean install de la Beta 2 et en se linkant
proprement à Java 5, ça marche.
En revanche, l'export/import est... buggé. Heureusement que l'export est
en XML, ça permet de limiter la casse (réimport à la main, en perdant
l'historique des pages).
> Il arrive même à m'effacer
> des pages que j'ai codées bas niveau.
Cela viendrait de pages codées un peu trop bas niveau...
Dans les cas courants, le WYSIWYG fonctionne bien. Ainsi, un copier /
coller de tableau depuis Word 2002 vers Firefox (sous Windows)
fonctionne bien et bluffe tout le monde.
--
David