Hi Pierre, all, I think perhaps my proposal was short and therefore your understanding of it is a bit different than what I had in mind. So I list below more specifically what I mean about each point from the ones you mentioned above to further fine-tune the discussion.
- The difference between createComponent and createPlugin is that the plugin resides in /plugins instead of hot-deploy and added to component-load.xml and also contains a build.gradle file designed specifically for plugins. This script contains standard tasks like install, uninstall, perhaps even upgrade. The magic work for plugins will be in their build scripts to integrate tightly with OFBiz. - The activate/deactivate tasks are just a little convenience tasks that add/remove components to the component-load.xml instead of editing it by hand so it is just using what exists. Gradle completely ignores a component if it does not exist in component-load.xml and would not even compile it. So you can think of this as just providing more ease to the end-user, similar to your suggestion with the createComponent. - The install/uninstall tasks are not just a copy-paste of folders. It actually executes business logic (optionally) for any plugin author who wishes to execute it (by calling specific tasks in build.gradle for that plugin). For example, it might apply patches on some core applications (and reverse patches in case of uninstall). Now our standard plugins do not touch applications or framework, but since we are introducing this feature I'm trying to also combine a unified solution for all plugins (Apache supported and 3rd party). So in one shot we have both ease of use for the existing components and at the same time a general purpose plugin system. We might even have a task like say "updatePlugin" in the future and it is also possible to introduce rudimentary dependency management (Gradle is really good at this). Finally, what to do about specialpurpose is something we should definitely tackle, however what I am suggesting right now is some foundational work that gives you easy choices when you need to make them, and it has the added bonus of introducing a plugin system for OFBiz which is badly needed to protect the core framework and applications and to provide an eco-system around it. I'm trying to reach a win-win solution if you will. Regards, Taher Alkhateeb On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 19/07/2016 à 22:57, Jacques Le Roux a écrit : > >> the graph needs to be checked/amended to possibly remove components >> dependencies only introduced by the data model >> > Sorry, I have noticed I have the bad tendency of using the word > "introduced" instead of "put" or "add" (due to "introduire" false friend in > French) please replace for me when you see it, thanks! :) > Here the right word would have been "due to" instead of "introduced by" > > Jacques > > PS: http://www.etymonline.com/index.php?term=introduction > >
