Je suis bete et discipliné donc j'ai appliqué la doc d'install a la lettre.
A l'étape B on me demande une opération d'import du projet generateur.
Hors ce dernier a pas été encore téléchargé à l'tape A car pas indiqué. Il faudrait ajouter dans l'étape A (Téléchargement et installation), l'opération à faire pour récuper le generateur sur son disque (lien ou commande svn qui a ete donné par mail à reporter dans la doc).
D'ailleurs faut-il importer dolibarr ou dolibarr.demo ou les 2 ?


Je suis parti du principe que j'ai importé les 2 apres recup par svn.
Ensuite je suis passé au chapitre III.
On y parle du "Package configModule". J'imagine que cela signifie qu'il faut qu'on dessine ce diagramme.
Et la je bloque. Ayant peu d'expérience sur l'utilisation d'UML au sein d'Eclipse, est-il possible d'indiquer les entrées menu dans Eclipse à utiliser pour pouvoir faire cette action ?

C'est noté pour la récupération du projet, je le rajouterai dans la doc dès lundi ainsi que quelques notes sur l'utilisation de topcased (modeleur UML).

Concernant le diagramme il n'est en fait pas nécessaire de le redessiner complètement. Le plus simple de de faire une copie du projet de démonstration et de le modifier selon ses besoin. La documentation permet alors de savoir quoi aller modifier et où pour adapter la solution.

Sur le 2 projets, seul le projet "dolibarr" est nécessaire à la génération, le module de démonstration est cependant fortement recommandé pour avoir un exemple complet d'utilisation et car il est plus simple de modifier quelque chose d'existant que de redessiner le diagramme.

Quelques petites indications :
- Dans le diagramme (.umldi) les flèches verte dans la barre d'outil permet de naviguer dans les package. La flèche vers le haut pour aller au package parent, double click sur un package pour l'explorer.
- Sur n'importe quel objet du digramme, clic droit -> "show properties" permet d'afficher les propriétés de l'objet.
- La sous partie "stéréotypes attributes" des propriétés contient généralement les paramètres modifiables pour l'objet sélectionné.
- La sous parte "stéréotypes" des propriétés contient la liste des stéréotypes appliquées à l'objet (et permet d'en appliquer sur une nouvelle classe ou sur une propriété)

Plus de détails seront dans la documentation dès lundi, ces indications devraient permettre de tester un peu pour commencer.

Nous venons de rajouter les informations manquantes à la doc :
- telechargement du generateur.
- petite documentation de topcased.
- documentation sur le code générés (screen, dao, services) avec le detail des methodes pour les dao et services.


S'il y a d'autres soucis dans la doc ou le generateur n'hesite pas à nous l'indiquer.

Merci. Quelques questions.

QUESTION 1:

Il y a un fichier .uml et un .umldi
Si j'ai bien compris, il faut choisir entre TopCased qui se sert du umldi ou un autre editeur uml à la norme 2.1 (genre argouml ?) et qui se servira de .uml ?
Si oui je ferais 2 sous repertoires dans models
models/fortopcased/*.umldi
models/foruml21/*.uml
par exemple pour qu'on comprenne qu'on a besoin que de 2 fichiers sur les 4 ou des 2 autres

QUESTION 2:

La generation se fait en cliquant sur le fichier .chain dans le rep chains. Est-ce un standard ? Peux-tu y placer le script convert.sh dans chains.
Ainsi dans chains on a les outils de generation puis convertion (la generation pure) et dans doc la doc uniquement.


QUESTION 3:

Les fichiers générés arrivent dans generateSrc ou, ailleurs et generateSrc sert juste de model ?
Si les fichiers générés arrivent dans generateSrc, ne se retrouvent-ils mélangés aux fichiers "modèles" ?

Réponse 1 :
Le umldi contient les informations du diagramme uniquement, et le uml les informations du modèle.

On peut donc choisir de modifier le modèle à travers le diagrammme umldi via topcased, ou éditer directement le uml via un autre modeleur. Dans tous les cas le .uml est obligatoire, et pour que topcased fonctionne bien on est obligé d'avoir le .uml dans le même répertoire que le .umldi.

Quand aux fichiers profile.uml et profile.umldi il n'y a pas besoin d'y toucher. Ils sont requis mais n'ont pas besoin d'être modifiés.

Réponse 2 :
Pour le moment il est nécessaire en effet de générer en faisant un clic droit->générer sur la .chain. C'est la façon de faire qu'à choisi acceleo et il n'y a pour le moment pas d'autre alternative que de générer, puis de convertir.

Cependant, la version 3 d'acceleo devrait sortir d'ici la fin du mois de juillet et fonctionnera en stand-alone. Elle permettra donc la ligne de commande, voire permettra de générer directement de l'iso. (Nous ne avons fait la demande à Acceleo et il semblerai que ça soit possible, sinon nous verrons pour faire un script génération + conversion)

Réponse 3 :
Les fichiers générés arrivent uniquement dans generatedSrc. Ce dossier peut être changé en modifiant generateModule.chain (double clic dessus) et en modifiant le chemin contenant "generatedSrc". On peut alors générer directement dans le projet dolibarr pourquoi pas.

Par fichiers "modèles", parles-tu des templates servant de modèle à la génération ou des modèles uml ?
Les templates sont dans un autre projet, ils ne sont pas du tout affectés par cette génération.
Les modèles uml sont dans le dossier "models", et les fichiers générés dans "generatedSrc" juste à coté mais aucun "mélange" ne se fait entre les 2.

Non par fichier modele, je voulais parler des fichiers qui sont dans generatedSrc (ce qu'on trouve apres un checkout svn).

Vu que la génération se fait aussi dans generatedSrc, qu'adviens-t-il des fichier dans generatedSrc ? Il cohabite avec les fichiers générés ?

je vois!

Les fichiers dans generatedSrc sont pré-générés et convertis en iso pour ceux voulant tester directement le contenu généré de la démo sans avoir à lancer la génération. Il peuvent donc être supprimés en cas de modification du modèle et seront recréés à la prochaine génération.

Acceleo gère aussi la possibilité de regénérer sans perdre les ajouts utilisateur (le code situé entre des balises //startUserCode et //endUserCode n'est pas regénéré). Tout le reste est regénéré. Donc lancer une génération, sachant que des fichiers sont déja générés, entraînera la modification du code à modifier sauf celui inclus dans les balises.

Dans ce projet, un grand nombre d'infos et de fichiers sont amenés à être modifiés entièrement donc nous avons mis ces balises à titre préventif pour protéger le code modifié. Pour tester les possibilités du générateur ou pour refaire les fichiers proprement générés, il est préférable de supprimer complètement le dossier generatedSrc, puis de relancer la génération qui recréera les fichiers.