Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • pas seulement installed/uninstalled, mais aussi deployed et undeployed pour le status des plugin
    • uninstalled et installed ne servent a rien comme status en fait, vu qu'un plugin uninstalled n'est ni dans le store ni dans la registry et un plugin installed est un plugin dans le store
    • en revanche, il faut un mechanisme pour stocker le status des plugins qui sont dans le store (deployed/undeployed)
  • il peut y avoir plusieurs type de plugins par registry pour eliminer la necessite d'avoir n registries pour n types de plugins
  • gestion des dependances interplugin
  • mechanisme d'injection de plugin dans d'autres plugins par annotations => j'essplique

    genre un plugin a besoin d'un autre plugin au moment de son instanciation, on annote un setter de telle facon que la registry peut injecter le plugin voulu

    genre:
    @InjectPlugin(family="truc",plugin="bidule")
    public void setBidule(Bidule bidule){
    ...
    }
  • revoir toutes les exceptions, leurs constructeurs, voir si on peut pas en passer en unchecked

23:47 - greg
je vois pas à quoi va servir l'annotation, l'injection pourrait etre déjà gérée par spring ou pico ou autre

...

  • On a besoin de "metadata" differents pour chaque type de plugin. La solution cra-cra adoptée par Tonic, c'est de passer un Element dom au builder/deployer/whatever. Solution plus propre: modéliser ça dans des beans. . Suis tenté de jeter un oeil à  à modello (cfr maven2 qui génère ses classes de model depuis un genre d'xsd, ce qui permet aussi de generer de la doc etc...). Ca n'implique pas necessairement une dépendence sur un format xml, mais ça pourrait etre une des possibilités les plus simples pour les users? On pourrait meme probablement générer un xsd qui supporterait tous les types de plugins qu'on fournirait - tout en laissant la possibilité aux users d'utiliser / implementer les types de plugins de leur choix.