Hi Nicolas, Actually as I was discussing this with Jacques in one of the JIRAs he mentioned something which I found very interesting:
If we create a full plugin API for creating a new plugin from templates and we provide everything necessary for updating then perhaps hot-deploy is even not that necessary anymore! it could simply be replaced with ./gradlew installPlugin -PpluginName=thePluginExistingInFolder. Also .. a lot of customization can be done with flags. So using your example we can perhaps say something like: ./gradlew installPlugin -PpluginName=birt -Prepository=org.apache.ofbiz or ./gradlew installPlugin -PpluginName=MyPlugin -Prepository=local or ./gradlew installPlugin -PpluginName=commercialPlugin -Prepository=com.someCompany first one is default which is official OFBiz plugin, second one is local file system, third one is commercial plugin for a company. Also we can define a task in every plugin called "installDependencies" or something like that which checks for dependent plugins and install them. We can go crazy with this :) A lot of ideas are ringing in my head. Taher Alkhateeb On Friday, 22 July 2016, Nicolas Malin <nicolas.ma...@nereide.fr> wrote: > Hi, > > Taher I like you proposal, and I wish to add some complement :) > > hot-deploy is to manage specific customer site component with the business > logic specific to each, Apache OFBiz can help to prepare this but do not > more (I will like to have this as best practice) > > I agree to add a new directory plugins and structure it for the future > vision : > * add capacity to download a plugin from the asf repo > * support extension to download from a third plateform (like the > /etc/apt/source.list on debian) > * manage namespace and as you said dependencies. Need give some coding > contions > > We can create the plugins directory, and keep specialpurpose on a first > step and move step by step each component present. > > I imagine a process like this : > * ./gradlew installPlugin org.apache.ofbiz.framework.birt : > -> check if birt is present on the plugins directory, if not download > from > svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt > -> enable it on component-load > -> compile, load init date and run init service > > When you run ./gradlew installAllPlugin : > * Realize installPlugin on all know plugins, with the official apache > ofbiz release, only plugins present on > svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/ > > Nicolas > > Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit : > >> 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 >>> >>> >>> >
