wiki:AncestrisDevPlugins

Le développement de plugins

Installation de Netbeans

La première chose à faire est d'installer Netbeans et de reprendre le source d'Ancestris. Toutes les explications sont données, à la fois sur ce site et sur le wiki d'Ancestris. Il faut vous y reporter.

Comment faire un plugin

Voici un lien qui vous présente la manière de faire son premier plugin avec Netbeans. C'est en anglais, donc si quelqu'un veut traduire ou compléter cette aide, surtout n'hésitez pas.

Numérotation des versions

Chaque module (ou plugin) pour l'application Ancestris doit avoir un numéro de version afin de pouvoir être correctement mis à jour par le mécanisme de mise à jour des plugins. Ce schéma de numérotation des modules Ancestris suit la convention standard des modules NetBeans décrite dans ce document avec quelques précisions suivantes:

  • La version finale (Major version) n'est pas utilisée pour le moment et sera considérée comme étant -1 par NetBeans
  • La version d'implémentation n'est pas utilisée pour le moment
  • La version de spécification sera sous la forme x.y.z.t avec:
    • x.y = version fonctionnelle du module
    • z = 0 pour les version de développement. ensuite ce nombre est incrémenté en fonction des release du module dans sa version w.y
    • t = release number, correspond à un bugfix. Ce nombre ne doit pas être mis dans les propriété du module, il est automatiquement inscrit par le processus de construction du module si on a bien pris la précaution d'utiliser les tâches ancestris dans le build.xml. Voir par exemple le build.xml des modules de la distribution standard. Il correspond à la version svn du répertoire du module considéré.

L'idée général est que, pour qu'un module puisse être mis à jour il faut que x.y.z.t du nouveau soit > à l'ancien. Chaque développeur de module doit donc veillez à positionner correctement cette version par exemple à l'aide des propriétés du module.

Nommage des modules

Il n'existe pas de convention de nommage à proprement parlé mais plutôt une règle adoptée pour les modules ancestris. Cette règle n'a aucun caractère obligatoire mais est utilisée pour le développement des principaux modules Ancestris et est recommandée pour les développements associés afin de garder une certaine homogénéité du projet.

Répertoire::

C'est aussi le nom du projet dans NetBeans. Il peut être le même que le nom de base du module mais ce n'est pas nécessaire. Il faut juste qu'il soit suffisamment explicite. Il est tout de même recommandé d'utiliser soit le nom de base soit la partie du nom de base après ancestris (par exemple api.editor pour ancestris.api.editor)

Nom affiché::

Ce nom sera celui affiché dans la gestion des plugin d'ancestris ainsi que dans l'affichage du nom des modules dans l'application ancestris elle-même.

Nom de base de code::

L'aide de NetBeans indique ceci:
uniquely identifies the module. Sets OpenIDE-Module in the MANIFEST.MF file. This line in the MANIFEST.MF file identifies the JAR file as a module, and provides its code name. If you expose APIs, the code name is what other modules will use to refer to your module when they declare a dependency on it. The standard convention is for the name to match the package structure of the module.

Ce sera donc le nom du package principal de ce module. Il est généralement d'usage de mettre le nom de domaine suivi du chemin d'accès au module. Par exemple org.apache.velocity. Pour des raisons historique dans les développement Ancestris il est conseillé d'omettre le premier org. Par exemple pour l'éditeur Ancestris, on aura: ancestris.modules.editors.standard.

Au final on aura donc, pour le module editeur ancestris:

  • Répertoire: modules.editors.standard (ici ancestris est omis pour ne pas trop surcharger)
  • Nom affiché: Ancestris Standard Editor
  • Nom de base de code: ancestris.modules.editors.standard.

nommage des packages

les différents packages pour ancestris utilisent l'espace de nommage ancestris.*. les conventions suivantes sont utilisées:

  • ancestris.core modules ancestris de base
  • ancestris.api Définition des différentes API pour les services fournis par les différents modules
  • ancestris.libs Correspond aux différentes bibliothèques incluses dans un module afin d'être utilisée dans ancestris (Wrapped Library). Par exemple libs.apache.velocity
  • ancestris.modules la plupart des modules d'ancestris
  • ancestris.modules.editors editeurs
  • ancestris.modules.views différentes vues (tables, ...
  • ancestris.modules.wizards assistants
  • ancestris. A compléter ...
  • genj.* Ancestris utilisant les développements effectués pour genj, les modules repris de ces développements sont sous l'arborescence genj
Last modified 5 years ago Last modified on Jun 25, 2012, 11:33:24 PM