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

Reply via email to