Oh I see Ron, this is already implemented. Every plugin can have a build.gradle file. This file declares the dependencies specific to that plugin (which actually points to jcenter).
So that part is already done for you :) now we need to figure out the plugin API which was being discussed in the last few emails. On Fri, Jul 22, 2016 at 5:53 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > I was thinking more about the 3rd party artifacts that can not be included > in releases but need to be installed before OFBiz can run. > > I guess that I am assuming that eventually a user will get some sort of > installer that will take all of the various components developed by OFBiz, > find all of the (OFBiz and3rd-party libraries) libraries required to run > the options (plug-ins or core features) selected during the installation > dialogue and organize them in a folder structure and run the required setup > processes to load the seed data and load any industry or > application-specific seed data selected. > > I am also looking forward to the day that the framework will be available > as a separate product with no dependencies on the ERP and the ERP will > have a number of modules with a hierarchy of dependencies rather than a web. > > > Ron > > > On 22/07/2016 10:12 AM, Taher Alkhateeb wrote: > >> Hi Ron, >> >> Maven and Jcenter are jar repositories. OFBiz components are not jars, so >> I >> am not sure but I think it would not fit, unless perhaps we can jar and >> unjar the folder not sure. >> >> On Friday, 22 July 2016, Ron Wheeler <rwhee...@artifact-software.com> >> wrote: >> >> For 3rd party libraries, would Maven Central be a good source? >>> Everything is there that does not need a license to access >>> There is a well defined and well supported service for getting artifacts. >>> >>> Ron >>> >>> On 22/07/2016 9:31 AM, Nicolas Malin 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>> Ron Wheeler >>> President >>> Artifact Software Inc >>> email: rwhee...@artifact-software.com >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >