org.projectforge.plugins.core.AbstractPlugin (ServiceLoader)IHKPlugin comme implémentation de org.projectforge.plugins.core.AbstractPlugin. Ce fichier d'une seule ligne est le mécanisme par lequel le plugin IHK est découvert et chargé à l'exécution.org.projectforge.plugins.ihk.IHKPlugin
Ce fichier se trouve au chemin standard Java ServiceLoader META-INF/services/{nom-d-interface-entièrement-qualifié}. Lorsque le scanner de plugins de ProjectForge invoque ServiceLoader.load(AbstractPlugin.class), la JVM lit tous ces fichiers depuis le classpath, instancie chaque classe listée et appelle initialize() sur chaque instance de plugin.
PFPluginService (ou un scanner de plugins équivalent) appelle ServiceLoader.load(AbstractPlugin.class).META-INF/services/org.projectforge.plugins.core.AbstractPlugin dans chaque JAR de plugin ou entrée de classpath.AbstractPlugin enregistre les métadonnées du plugin (ID, nom, description).initialize(), où IHKPlugin effectue ses enregistrements DAO, web, menu, droits et i18n.java.util.ServiceLoader plutôt que le scan @Component de Spring pour la découverte des plugins. Cela permet de charger les plugins depuis des JARs externes déposés dans un répertoire de plugins, indépendamment des packages de base du scan de composants Spring.IHKPlugin.IHKPlugin lui-même ne soit pas un bean Spring, les composants qu'il câble (via WicketSupport.get()) sont gérés par Spring. Cette approche hybride maintient le cycle de vie du plugin séparé de celui du contexte Spring.org.projectforge.plugins.todo.ToDoPlugin (voir #287), le plugin Memo a org.projectforge.plugins.memo.MemoPlugin, etc.50d5d8926 wip : META-INF/services nécessaire pour les plugins (chargeur de services) 07b80966b wip : PFPluginService (PluginConfig) -> PluginInfo 45cad02e9 Plugin IHK ajouté (remplacera le plugin "Ihk-Export")