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 > >
