Packages, manifests et applications

Statut documentaire : reference — voir Maturité et preuves.

Packages

Un package est l’unité de déploiement et de chargement d’un groupe de ressources de modèle. Les racines de modèles, chemins de vues, services et ressources doivent être explicites plutôt que dépendre de chemins de recherche implicites.

Class manifests

Un class manifest est une allow-list. Il empêche qu’un fichier obsolète ou expérimental entre dans l’application simplement parce qu’il se trouve dans un dossier.

Utiliser une identité conceptuelle stable : une signification -> un classId stable. Ne réutiliser un identifiant que pour la même identité conceptuelle ou un mécanisme explicite de redéfinition supporté.

package:
  plugginCaption: TaskManagement
  uri: http://www.logicells.net/package/TaskManagement
  classes:
    - Task:
        classId: app#task
        type: Entity
    - Project:
        classId: app#project
        type: Entity
    - TaskBelongsToProject:
        classId: app#task_belongs_to_project
        type: Relation

Applications

La configuration application répond à la question : quelles ressources Runtime sont assemblées pour rendre cette application conceptuelle exécutable ?

Y placer les préoccupations d’environnement : alias de base, chemins, packages activés, groupes de services, ports, ressources et options Runtime. Préférer une configuration mémoire pour le premier diagnostic et une configuration persistante pour la validation proche production.

Séquence de validation

1. Le fichier application est trouvé et accepté.
2. Le package attendu est activé.
3. Le package résout sa racine de modèles.
4. Le manifest est trouvé et compilé.
5. Le modèle est trouvé et compilé.
6. Le classId résout le bon concept Runtime.
7. L’initialisation conceptuelle se termine sans conflit d’identité.