[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

[taher]

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 <[hidden email]> 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 <
>> [hidden email]> 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]

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 <
>> [hidden email]> 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: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[taher]

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 <[hidden email]> 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 <
>>> [hidden email]> 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: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Ron Wheeler]

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 <[hidden email]> 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 <
>>>> [hidden email]> 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: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[taher]

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 <[hidden email]
> 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 <[hidden email]>
>> 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 <
>>>>> [hidden email]> 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: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: [phone], ext 102
>>>
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Ron Wheeler]

This is a great step forward.

Thanks
Ron

On 22/07/2016 11:49 AM, Taher Alkhateeb wrote:

> 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 <[hidden email]
>> 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 <[hidden email]>
>>> 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 <
>>>>>> [hidden email]> 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: [hidden email]
>>>> skype: ronaldmwheeler
>>>> phone: [phone], ext 102
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> 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 think plugins could do that also

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

This should be in the specifications indeed, Taher already answered

>
> We can create the plugins directory, and keep specialpurpose on a first step and move step by step each component present.

This is a very important point and we have to be very careful about the transition!

Jacques

>
> 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 <
>> [hidden email]> 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
>>>
>>>
>
>

[Jacques Le Roux]

Taher, Nicolas,

I like you plan Taher.

I had a small discussion with Nicolas by phone on this subject before he wrote his answer. I told me that he prefers to separate the OOTB things (aka
specialpurpose now) from the outside things (aka hot-deploy now)

I still think that if we have real plugins (a sole plugins folder with sub-folders for plugins - still to be clearly defined -, ie not current
components) he does not make sense to separate these two aspects.

But I'd need Nicolas to clarify why he thinks so.

Is it for legacy reasons (due to Neereides addons for instance)?

Does he has another plan?

Or does he have other reasons?

I know Nicolas has a long experience with addons, so it's worth to listen his opinion before engaging to specify OFBiz plugins.

IIRW Neereides addons were using Ivy and patches, and we are proposing something new with Gradle and its jars dependencies engine + a specific DSL +
Groovy and the possibility to call Ant targets (eg for legacy transition). Did I miss something :) ?

Thanks

Jacques


Le 22/07/2016 à 15:58, Taher Alkhateeb a écrit :

> 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 <[hidden email]> 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 <
>>> [hidden email]> 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
>>>>
>>>>
>>>>

[Gil Portenseigne]

Hi all,

First, I like the idea of gradle being the plugin solution endebbed within OFBiz.

This could allow OFBiz integrators to share their specific improvments with a easy to use, OOTB tool (thinking about OfbizExtra addons or Pierre's OEM initiatives to name a few).

Then, from what i understand about what Nicolas said, is that it'd be good to keep hot-deploy and create-component tasks for customer projects.

Why not using plugin into customer project ? It is because that is a private, specific and complete new application using core and plugin functionnalities. It has to be separated since it is not a plugin (not intended to be shared). The plugin dependency could be solved with a build.gradle within the hot-deploy component, checking the installation state of the dependent plugin (and installing if needed).

And last, for your information, Nereide do not use addons anymore, this system created more problems than it helped, the original idea was good, but some design flaws did showed up...

Gil

Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :

Le 22/07/2016 à 15:31, Nicolas Malin a écrit :

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 think plugins could do that also

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

This should be in the specifications indeed, Taher already answered

We can create the plugins directory, and keep specialpurpose on a first step and move step by step each component present.

This is a very important point and we have to be very careful about the transition!

Jacques

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 <
[hidden email]> 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

[taher]

Hi Gil,

Thank you for sharing past experiences. It seems we are tackling something
that was attempted multiple times before. I am a bit optimistic though
because having the plugin system integrated into the build system is a
different approach that solves multiple problems I think.

I would like to note that I think it is okay to use the same plugin system
even for proprietary customer solutions. In fact I think customers would
understand it more easily than the concept of hot-deploy. Even if the
solution is for one customer and not intended to be shared you can still
have a sensible command like ./gradlew installPlugin
-PpluginName=customerPlugin -Prepository=localFileSystem.

Having one solution instead of two solutions I think would unify efforts
and thinking processes and terminology used. We have only one way of
extending OFBiz which is called plugins, and any changes we do happen in
this unified architecture.

So ... food for thought.

Taher Alkhateeb

On Jul 23, 2016 7:34 PM, "gil portenseigne" <[hidden email]>
wrote:

> Hi all,
>
> First, I like the idea of gradle being the plugin solution endebbed within
> OFBiz.
>
> This could allow OFBiz integrators to share their specific improvments
> with a easy to use, OOTB tool (thinking about OfbizExtra addons or Pierre's
> OEM initiatives to name a few).
>
> Then, from what i understand about what Nicolas said, is that it'd be good
> to keep hot-deploy and create-component tasks for customer projects.
>
> Why not using plugin into customer project ? It is because that is a
> private, specific and complete new application using core and plugin
> functionnalities. It has to be separated since it is not a plugin (not
> intended to be shared). The plugin dependency could be solved with a
> build.gradle within the hot-deploy component, checking the installation
> state of the dependent plugin (and installing if needed).
>
> And last, for your information, Nereide do not use addons anymore, this
> system created more problems than it helped, the original idea was good,
> but some design flaws did showed up...
> Gil
>
>
>
> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
>
>
>
> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
>
> 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 think plugins could do that also
>
>
> 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
>
>
> This should be in the specifications indeed, Taher already answered
>
>
> We can create the plugins directory, and keep specialpurpose on a first
> step and move step by step each component present.
>
>
> This is a very important point and we have to be very careful about the
> transition!
>
> Jacques
>
>
> 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 <
> [hidden email]> 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
>
>
>
>
>
>
>

[Jacques Le Roux]

Hi Taher, Gil,

Exactly my thoughts. Nothing (ethically and technically) should force an user to share his/her/its personal plugins. This assumption must be part of
the specifications (assumption as in a theory)

Thanks Taher!


Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :

> Hi Gil,
>
> Thank you for sharing past experiences. It seems we are tackling something
> that was attempted multiple times before. I am a bit optimistic though
> because having the plugin system integrated into the build system is a
> different approach that solves multiple problems I think.
>
> I would like to note that I think it is okay to use the same plugin system
> even for proprietary customer solutions. In fact I think customers would
> understand it more easily than the concept of hot-deploy. Even if the
> solution is for one customer and not intended to be shared you can still
> have a sensible command like ./gradlew installPlugin
> -PpluginName=customerPlugin -Prepository=localFileSystem.
>
> Having one solution instead of two solutions I think would unify efforts
> and thinking processes and terminology used. We have only one way of
> extending OFBiz which is called plugins, and any changes we do happen in
> this unified architecture.
>
> So ... food for thought.
>
> Taher Alkhateeb
>
> On Jul 23, 2016 7:34 PM, "gil portenseigne" <[hidden email]>
> wrote:
>
>> Hi all,
>>
>> First, I like the idea of gradle being the plugin solution endebbed within
>> OFBiz.
>>
>> This could allow OFBiz integrators to share their specific improvments
>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or Pierre's
>> OEM initiatives to name a few).
>>
>> Then, from what i understand about what Nicolas said, is that it'd be good
>> to keep hot-deploy and create-component tasks for customer projects.
>>
>> Why not using plugin into customer project ? It is because that is a
>> private, specific and complete new application using core and plugin
>> functionnalities. It has to be separated since it is not a plugin (not
>> intended to be shared). The plugin dependency could be solved with a
>> build.gradle within the hot-deploy component, checking the installation
>> state of the dependent plugin (and installing if needed).
>>
>> And last, for your information, Nereide do not use addons anymore, this
>> system created more problems than it helped, the original idea was good,
>> but some design flaws did showed up...
>> Gil
>>
>>
>>
>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
>>
>>
>>
>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
>>
>> 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 think plugins could do that also
>>
>>
>> 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
>>
>>
>> This should be in the specifications indeed, Taher already answered
>>
>>
>> We can create the plugins directory, and keep specialpurpose on a first
>> step and move step by step each component present.
>>
>>
>> This is a very important point and we have to be very careful about the
>> transition!
>>
>> Jacques
>>
>>
>> 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 <
>> [hidden email]> 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
>>
>>
>>
>>
>>
>>
>>

[taher]

Hi everyone,

In continuation with the above discussion, I just made a little experiment
which gave me scary results. What did I do?

1 - Disabled all specialpurpose components (except example, to make it a
valid XML file) in specialpurpose/component-load.xml
2 - Attempted ./gradlew cleanAll loadDefault testIntegration
3 - Got 100 failing tests

So upon investigating a little I believe these tests fail due to multiple
issues:
- When we disable specialpurpose, the dependency graph for Jars changes and
that breaks some system behavior
- I suspect also some data loading is disabled which fails some of the tests
- hidden dependencies exist from framework / applications to specialpurpose.

What does that mean? It means our framework is brittle and depends on
specialpurpose, and without it being active the system does not run
properly.

If we are serious about improving the system and making it modular, then I
find it very important to start with disabling all specialpurpose
components or at least having a second build in buildbot for those
components in isolation of the framework.

I don't think this is a luxury, I highly recommend that we stop the
specialpurpose components from being active by default to protect and
isolate the framework and core applications. Actually we need help from
everyone who is willing to help to volunteer in getting a working build
with tests passing while all specialpurpose components are disabled.

Taher Alkhateeb

On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
[hidden email]> wrote:

> Hi Taher, Gil,
>
> Exactly my thoughts. Nothing (ethically and technically) should force an
> user to share his/her/its personal plugins. This assumption must be part of
> the specifications (assumption as in a theory)
>
> Thanks Taher!
>
>
>
> Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
>
>> Hi Gil,
>>
>> Thank you for sharing past experiences. It seems we are tackling something
>> that was attempted multiple times before. I am a bit optimistic though
>> because having the plugin system integrated into the build system is a
>> different approach that solves multiple problems I think.
>>
>> I would like to note that I think it is okay to use the same plugin system
>> even for proprietary customer solutions. In fact I think customers would
>> understand it more easily than the concept of hot-deploy. Even if the
>> solution is for one customer and not intended to be shared you can still
>> have a sensible command like ./gradlew installPlugin
>> -PpluginName=customerPlugin -Prepository=localFileSystem.
>>
>> Having one solution instead of two solutions I think would unify efforts
>> and thinking processes and terminology used. We have only one way of
>> extending OFBiz which is called plugins, and any changes we do happen in
>> this unified architecture.
>>
>> So ... food for thought.
>>
>> Taher Alkhateeb
>>
>> On Jul 23, 2016 7:34 PM, "gil portenseigne" <[hidden email]>
>> wrote:
>>
>> Hi all,
>>>
>>> First, I like the idea of gradle being the plugin solution endebbed
>>> within
>>> OFBiz.
>>>
>>> This could allow OFBiz integrators to share their specific improvments
>>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
>>> Pierre's
>>> OEM initiatives to name a few).
>>>
>>> Then, from what i understand about what Nicolas said, is that it'd be
>>> good
>>> to keep hot-deploy and create-component tasks for customer projects.
>>>
>>> Why not using plugin into customer project ? It is because that is a
>>> private, specific and complete new application using core and plugin
>>> functionnalities. It has to be separated since it is not a plugin (not
>>> intended to be shared). The plugin dependency could be solved with a
>>> build.gradle within the hot-deploy component, checking the installation
>>> state of the dependent plugin (and installing if needed).
>>>
>>> And last, for your information, Nereide do not use addons anymore, this
>>> system created more problems than it helped, the original idea was good,
>>> but some design flaws did showed up...
>>> Gil
>>>
>>>
>>>
>>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
>>>
>>>
>>>
>>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
>>>
>>> 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 think plugins could do that also
>>>
>>>
>>> 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
>>>
>>>
>>> This should be in the specifications indeed, Taher already answered
>>>
>>>
>>> We can create the plugins directory, and keep specialpurpose on a first
>>> step and move step by step each component present.
>>>
>>>
>>> This is a very important point and we have to be very careful about the
>>> transition!
>>>
>>> Jacques
>>>
>>>
>>> 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 <
>>> [hidden email]> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>

[Jacopo Cappellato-5]

I think that the core reason for the failure is that most of the tests need
the demo data that is loaded with the ecommerce component; if you disable
it the data is not loaded.
Could you please try to enable ecommerce and run them again?

Thanks,

Jacopo

On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi everyone,
>
> In continuation with the above discussion, I just made a little experiment
> which gave me scary results. What did I do?
>
> 1 - Disabled all specialpurpose components (except example, to make it a
> valid XML file) in specialpurpose/component-load.xml
> 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> 3 - Got 100 failing tests
>
> So upon investigating a little I believe these tests fail due to multiple
> issues:
> - When we disable specialpurpose, the dependency graph for Jars changes and
> that breaks some system behavior
> - I suspect also some data loading is disabled which fails some of the
> tests
> - hidden dependencies exist from framework / applications to
> specialpurpose.
>
> What does that mean? It means our framework is brittle and depends on
> specialpurpose, and without it being active the system does not run
> properly.
>
> If we are serious about improving the system and making it modular, then I
> find it very important to start with disabling all specialpurpose
> components or at least having a second build in buildbot for those
> components in isolation of the framework.
>
> I don't think this is a luxury, I highly recommend that we stop the
> specialpurpose components from being active by default to protect and
> isolate the framework and core applications. Actually we need help from
> everyone who is willing to help to volunteer in getting a working build
> with tests passing while all specialpurpose components are disabled.
>
> Taher Alkhateeb
>
> On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi Taher, Gil,
> >
> > Exactly my thoughts. Nothing (ethically and technically) should force an
> > user to share his/her/its personal plugins. This assumption must be part
> of
> > the specifications (assumption as in a theory)
> >
> > Thanks Taher!
> >
> >
> >
> > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> >
> >> Hi Gil,
> >>
> >> Thank you for sharing past experiences. It seems we are tackling
> something
> >> that was attempted multiple times before. I am a bit optimistic though
> >> because having the plugin system integrated into the build system is a
> >> different approach that solves multiple problems I think.
> >>
> >> I would like to note that I think it is okay to use the same plugin
> system
> >> even for proprietary customer solutions. In fact I think customers would
> >> understand it more easily than the concept of hot-deploy. Even if the
> >> solution is for one customer and not intended to be shared you can still
> >> have a sensible command like ./gradlew installPlugin
> >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> >>
> >> Having one solution instead of two solutions I think would unify efforts
> >> and thinking processes and terminology used. We have only one way of
> >> extending OFBiz which is called plugins, and any changes we do happen in
> >> this unified architecture.
> >>
> >> So ... food for thought.
> >>
> >> Taher Alkhateeb
> >>
> >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> [hidden email]>
> >> wrote:
> >>
> >> Hi all,
> >>>
> >>> First, I like the idea of gradle being the plugin solution endebbed
> >>> within
> >>> OFBiz.
> >>>
> >>> This could allow OFBiz integrators to share their specific improvments
> >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> >>> Pierre's
> >>> OEM initiatives to name a few).
> >>>
> >>> Then, from what i understand about what Nicolas said, is that it'd be
> >>> good
> >>> to keep hot-deploy and create-component tasks for customer projects.
> >>>
> >>> Why not using plugin into customer project ? It is because that is a
> >>> private, specific and complete new application using core and plugin
> >>> functionnalities. It has to be separated since it is not a plugin (not
> >>> intended to be shared). The plugin dependency could be solved with a
> >>> build.gradle within the hot-deploy component, checking the installation
> >>> state of the dependent plugin (and installing if needed).
> >>>
> >>> And last, for your information, Nereide do not use addons anymore, this
> >>> system created more problems than it helped, the original idea was
> good,
> >>> but some design flaws did showed up...
> >>> Gil
> >>>
> >>>
> >>>
> >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> >>>
> >>>
> >>>
> >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> >>>
> >>> 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 think plugins could do that also
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>> This should be in the specifications indeed, Taher already answered
> >>>
> >>>
> >>> We can create the plugins directory, and keep specialpurpose on a first
> >>> step and move step by step each component present.
> >>>
> >>>
> >>> This is a very important point and we have to be very careful about the
> >>> transition!
> >>>
> >>> Jacques
> >>>
> >>>
> >>> 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 <
> >>> [hidden email]> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>

[Pierre Smits]

The perception is growing that 2 different solutions are mixed into one...

One solution is about jump starting development, the other is about
on-boarding existing components into an OFBiz deployment.

If this plugin API/solution was intended for components existing outside of
the OFBiz repo (either publicly available in repos like GitHub, or in
private repos), I would understand the need for it.

But when code is already available in the OFBiz repo - and made available
through releases - such an enabler/disabler is as much overkill to an
adopter as a convenience script to download JDBC libraries (to paraphrase
another contributor).

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Jul 23, 2016 at 7:44 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Gil,
>
> Thank you for sharing past experiences. It seems we are tackling something
> that was attempted multiple times before. I am a bit optimistic though
> because having the plugin system integrated into the build system is a
> different approach that solves multiple problems I think.
>
> I would like to note that I think it is okay to use the same plugin system
> even for proprietary customer solutions. In fact I think customers would
> understand it more easily than the concept of hot-deploy. Even if the
> solution is for one customer and not intended to be shared you can still
> have a sensible command like ./gradlew installPlugin
> -PpluginName=customerPlugin -Prepository=localFileSystem.
>
> Having one solution instead of two solutions I think would unify efforts
> and thinking processes and terminology used. We have only one way of
> extending OFBiz which is called plugins, and any changes we do happen in
> this unified architecture.
>
> So ... food for thought.
>
> Taher Alkhateeb
>
> On Jul 23, 2016 7:34 PM, "gil portenseigne" <[hidden email]>
> wrote:
>
> > Hi all,
> >
> > First, I like the idea of gradle being the plugin solution endebbed
> within
> > OFBiz.
> >
> > This could allow OFBiz integrators to share their specific improvments
> > with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> Pierre's
> > OEM initiatives to name a few).
> >
> > Then, from what i understand about what Nicolas said, is that it'd be
> good
> > to keep hot-deploy and create-component tasks for customer projects.
> >
> > Why not using plugin into customer project ? It is because that is a
> > private, specific and complete new application using core and plugin
> > functionnalities. It has to be separated since it is not a plugin (not
> > intended to be shared). The plugin dependency could be solved with a
> > build.gradle within the hot-deploy component, checking the installation
> > state of the dependent plugin (and installing if needed).
> >
> > And last, for your information, Nereide do not use addons anymore, this
> > system created more problems than it helped, the original idea was good,
> > but some design flaws did showed up...
> > Gil
> >
> >
> >
> > Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> >
> >
> >
> > Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> >
> > 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 think plugins could do that also
> >
> >
> > 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
> >
> >
> > This should be in the specifications indeed, Taher already answered
> >
> >
> > We can create the plugins directory, and keep specialpurpose on a first
> > step and move step by step each component present.
> >
> >
> > This is a very important point and we have to be very careful about the
> > transition!
> >
> > Jacques
> >
> >
> > 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 <
> > [hidden email]> 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
> >
> >
> >
> >
> >
> >
> >
>

[taher]

Hi Jacopo,

You got it 100% right, it was indeed the ecommerce component. Wow! This
means one of two things should happen, either we move ecommerce as a core
application, or we untangle this mess. I'm not very familiar with the
history, is there a reason why ecommerce is a specialpurpose application?
it seems to be highly integrated within the framework.

Taher Alkhateeb

On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
[hidden email]> wrote:

> I think that the core reason for the failure is that most of the tests need
> the demo data that is loaded with the ecommerce component; if you disable
> it the data is not loaded.
> Could you please try to enable ecommerce and run them again?
>
> Thanks,
>
> Jacopo
>
> On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > Hi everyone,
> >
> > In continuation with the above discussion, I just made a little
> experiment
> > which gave me scary results. What did I do?
> >
> > 1 - Disabled all specialpurpose components (except example, to make it a
> > valid XML file) in specialpurpose/component-load.xml
> > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > 3 - Got 100 failing tests
> >
> > So upon investigating a little I believe these tests fail due to multiple
> > issues:
> > - When we disable specialpurpose, the dependency graph for Jars changes
> and
> > that breaks some system behavior
> > - I suspect also some data loading is disabled which fails some of the
> > tests
> > - hidden dependencies exist from framework / applications to
> > specialpurpose.
> >
> > What does that mean? It means our framework is brittle and depends on
> > specialpurpose, and without it being active the system does not run
> > properly.
> >
> > If we are serious about improving the system and making it modular, then
> I
> > find it very important to start with disabling all specialpurpose
> > components or at least having a second build in buildbot for those
> > components in isolation of the framework.
> >
> > I don't think this is a luxury, I highly recommend that we stop the
> > specialpurpose components from being active by default to protect and
> > isolate the framework and core applications. Actually we need help from
> > everyone who is willing to help to volunteer in getting a working build
> > with tests passing while all specialpurpose components are disabled.
> >
> > Taher Alkhateeb
> >
> > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > Hi Taher, Gil,
> > >
> > > Exactly my thoughts. Nothing (ethically and technically) should force
> an
> > > user to share his/her/its personal plugins. This assumption must be
> part
> > of
> > > the specifications (assumption as in a theory)
> > >
> > > Thanks Taher!
> > >
> > >
> > >
> > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > >
> > >> Hi Gil,
> > >>
> > >> Thank you for sharing past experiences. It seems we are tackling
> > something
> > >> that was attempted multiple times before. I am a bit optimistic though
> > >> because having the plugin system integrated into the build system is a
> > >> different approach that solves multiple problems I think.
> > >>
> > >> I would like to note that I think it is okay to use the same plugin
> > system
> > >> even for proprietary customer solutions. In fact I think customers
> would
> > >> understand it more easily than the concept of hot-deploy. Even if the
> > >> solution is for one customer and not intended to be shared you can
> still
> > >> have a sensible command like ./gradlew installPlugin
> > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> > >>
> > >> Having one solution instead of two solutions I think would unify
> efforts
> > >> and thinking processes and terminology used. We have only one way of
> > >> extending OFBiz which is called plugins, and any changes we do happen
> in
> > >> this unified architecture.
> > >>
> > >> So ... food for thought.
> > >>
> > >> Taher Alkhateeb
> > >>
> > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> > [hidden email]>
> > >> wrote:
> > >>
> > >> Hi all,
> > >>>
> > >>> First, I like the idea of gradle being the plugin solution endebbed
> > >>> within
> > >>> OFBiz.
> > >>>
> > >>> This could allow OFBiz integrators to share their specific
> improvments
> > >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> > >>> Pierre's
> > >>> OEM initiatives to name a few).
> > >>>
> > >>> Then, from what i understand about what Nicolas said, is that it'd be
> > >>> good
> > >>> to keep hot-deploy and create-component tasks for customer projects.
> > >>>
> > >>> Why not using plugin into customer project ? It is because that is a
> > >>> private, specific and complete new application using core and plugin
> > >>> functionnalities. It has to be separated since it is not a plugin
> (not
> > >>> intended to be shared). The plugin dependency could be solved with a
> > >>> build.gradle within the hot-deploy component, checking the
> installation
> > >>> state of the dependent plugin (and installing if needed).
> > >>>
> > >>> And last, for your information, Nereide do not use addons anymore,
> this
> > >>> system created more problems than it helped, the original idea was
> > good,
> > >>> but some design flaws did showed up...
> > >>> Gil
> > >>>
> > >>>
> > >>>
> > >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> > >>>
> > >>>
> > >>>
> > >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> > >>>
> > >>> 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 think plugins could do that also
> > >>>
> > >>>
> > >>> 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
> > >>>
> > >>>
> > >>> This should be in the specifications indeed, Taher already answered
> > >>>
> > >>>
> > >>> We can create the plugins directory, and keep specialpurpose on a
> first
> > >>> step and move step by step each component present.
> > >>>
> > >>>
> > >>> This is a very important point and we have to be very careful about
> the
> > >>> transition!
> > >>>
> > >>> Jacques
> > >>>
> > >>>
> > >>> 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 <
> > >>> [hidden email]> 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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
>

[Jacopo Cappellato-5]

Initially ecommerce was part of the "core" applications, then it was moved
to specialpurpose because as it it is a "template" for the implementation
of an ecommerce store rather than a ready to be used application.
I must admit that the same could apply to the other backend applications so
there is definitely a grey area...
For the short term we could consider to move the demo data up the stack.

Jacopo

On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Jacopo,
>
> You got it 100% right, it was indeed the ecommerce component. Wow! This
> means one of two things should happen, either we move ecommerce as a core
> application, or we untangle this mess. I'm not very familiar with the
> history, is there a reason why ecommerce is a specialpurpose application?
> it seems to be highly integrated within the framework.
>
> Taher Alkhateeb
>
> On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
> > I think that the core reason for the failure is that most of the tests
> need
> > the demo data that is loaded with the ecommerce component; if you disable
> > it the data is not loaded.
> > Could you please try to enable ecommerce and run them again?
> >
> > Thanks,
> >
> > Jacopo
> >
> > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> > [hidden email]
> > > wrote:
> >
> > > Hi everyone,
> > >
> > > In continuation with the above discussion, I just made a little
> > experiment
> > > which gave me scary results. What did I do?
> > >
> > > 1 - Disabled all specialpurpose components (except example, to make it
> a
> > > valid XML file) in specialpurpose/component-load.xml
> > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > > 3 - Got 100 failing tests
> > >
> > > So upon investigating a little I believe these tests fail due to
> multiple
> > > issues:
> > > - When we disable specialpurpose, the dependency graph for Jars changes
> > and
> > > that breaks some system behavior
> > > - I suspect also some data loading is disabled which fails some of the
> > > tests
> > > - hidden dependencies exist from framework / applications to
> > > specialpurpose.
> > >
> > > What does that mean? It means our framework is brittle and depends on
> > > specialpurpose, and without it being active the system does not run
> > > properly.
> > >
> > > If we are serious about improving the system and making it modular,
> then
> > I
> > > find it very important to start with disabling all specialpurpose
> > > components or at least having a second build in buildbot for those
> > > components in isolation of the framework.
> > >
> > > I don't think this is a luxury, I highly recommend that we stop the
> > > specialpurpose components from being active by default to protect and
> > > isolate the framework and core applications. Actually we need help from
> > > everyone who is willing to help to volunteer in getting a working build
> > > with tests passing while all specialpurpose components are disabled.
> > >
> > > Taher Alkhateeb
> > >
> > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > > > Hi Taher, Gil,
> > > >
> > > > Exactly my thoughts. Nothing (ethically and technically) should force
> > an
> > > > user to share his/her/its personal plugins. This assumption must be
> > part
> > > of
> > > > the specifications (assumption as in a theory)
> > > >
> > > > Thanks Taher!
> > > >
> > > >
> > > >
> > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > > >
> > > >> Hi Gil,
> > > >>
> > > >> Thank you for sharing past experiences. It seems we are tackling
> > > something
> > > >> that was attempted multiple times before. I am a bit optimistic
> though
> > > >> because having the plugin system integrated into the build system
> is a
> > > >> different approach that solves multiple problems I think.
> > > >>
> > > >> I would like to note that I think it is okay to use the same plugin
> > > system
> > > >> even for proprietary customer solutions. In fact I think customers
> > would
> > > >> understand it more easily than the concept of hot-deploy. Even if
> the
> > > >> solution is for one customer and not intended to be shared you can
> > still
> > > >> have a sensible command like ./gradlew installPlugin
> > > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> > > >>
> > > >> Having one solution instead of two solutions I think would unify
> > efforts
> > > >> and thinking processes and terminology used. We have only one way of
> > > >> extending OFBiz which is called plugins, and any changes we do
> happen
> > in
> > > >> this unified architecture.
> > > >>
> > > >> So ... food for thought.
> > > >>
> > > >> Taher Alkhateeb
> > > >>
> > > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> > > [hidden email]>
> > > >> wrote:
> > > >>
> > > >> Hi all,
> > > >>>
> > > >>> First, I like the idea of gradle being the plugin solution endebbed
> > > >>> within
> > > >>> OFBiz.
> > > >>>
> > > >>> This could allow OFBiz integrators to share their specific
> > improvments
> > > >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> > > >>> Pierre's
> > > >>> OEM initiatives to name a few).
> > > >>>
> > > >>> Then, from what i understand about what Nicolas said, is that it'd
> be
> > > >>> good
> > > >>> to keep hot-deploy and create-component tasks for customer
> projects.
> > > >>>
> > > >>> Why not using plugin into customer project ? It is because that is
> a
> > > >>> private, specific and complete new application using core and
> plugin
> > > >>> functionnalities. It has to be separated since it is not a plugin
> > (not
> > > >>> intended to be shared). The plugin dependency could be solved with
> a
> > > >>> build.gradle within the hot-deploy component, checking the
> > installation
> > > >>> state of the dependent plugin (and installing if needed).
> > > >>>
> > > >>> And last, for your information, Nereide do not use addons anymore,
> > this
> > > >>> system created more problems than it helped, the original idea was
> > > good,
> > > >>> but some design flaws did showed up...
> > > >>> Gil
> > > >>>
> > > >>>
> > > >>>
> > > >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> > > >>>
> > > >>>
> > > >>>
> > > >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> > > >>>
> > > >>> 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 think plugins could do that also
> > > >>>
> > > >>>
> > > >>> 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
> > > >>>
> > > >>>
> > > >>> This should be in the specifications indeed, Taher already answered
> > > >>>
> > > >>>
> > > >>> We can create the plugins directory, and keep specialpurpose on a
> > first
> > > >>> step and move step by step each component present.
> > > >>>
> > > >>>
> > > >>> This is a very important point and we have to be very careful about
> > the
> > > >>> transition!
> > > >>>
> > > >>> Jacques
> > > >>>
> > > >>>
> > > >>> 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 <
> > > >>> [hidden email]> 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
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >
> > >
> >
>

[Jacopo Cappellato-5]

On Wed, Jul 27, 2016 at 3:47 PM, Pierre Smits <[hidden email]>
wrote:

> ...
> But when code is already available in the OFBiz repo - and made available
> through releases - such an enabler/disabler is as much overkill to an
> adopter as a convenience script to download JDBC libraries (to paraphrase

another contributor).
>

I disagree based on the feedback I have received from several adopters over
the years (including, but not limited to, the company I work for): the
ability to deploy/enable only the required components is one of the most
frequently requested; on the other hand no one ever asked me an automation
script to download the JDBC driver of the database... but as I said in
another comment, every adopter is different from the others.

Jacopo

[Pierre Smits]

An issue regarding the move of data up the stack already exists:
https://issues.apache.org/jira/browse/OFBIZ-7016

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Initially ecommerce was part of the "core" applications, then it was moved
> to specialpurpose because as it it is a "template" for the implementation
> of an ecommerce store rather than a ready to be used application.
> I must admit that the same could apply to the other backend applications so
> there is definitely a grey area...
> For the short term we could consider to move the demo data up the stack.
>
> Jacopo
>
> On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > Hi Jacopo,
> >
> > You got it 100% right, it was indeed the ecommerce component. Wow! This
> > means one of two things should happen, either we move ecommerce as a core
> > application, or we untangle this mess. I'm not very familiar with the
> > history, is there a reason why ecommerce is a specialpurpose application?
> > it seems to be highly integrated within the framework.
> >
> > Taher Alkhateeb
> >
> > On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
> > [hidden email]> wrote:
> >
> > > I think that the core reason for the failure is that most of the tests
> > need
> > > the demo data that is loaded with the ecommerce component; if you
> disable
> > > it the data is not loaded.
> > > Could you please try to enable ecommerce and run them again?
> > >
> > > Thanks,
> > >
> > > Jacopo
> > >
> > > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> > > [hidden email]
> > > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > In continuation with the above discussion, I just made a little
> > > experiment
> > > > which gave me scary results. What did I do?
> > > >
> > > > 1 - Disabled all specialpurpose components (except example, to make
> it
> > a
> > > > valid XML file) in specialpurpose/component-load.xml
> > > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > > > 3 - Got 100 failing tests
> > > >
> > > > So upon investigating a little I believe these tests fail due to
> > multiple
> > > > issues:
> > > > - When we disable specialpurpose, the dependency graph for Jars
> changes
> > > and
> > > > that breaks some system behavior
> > > > - I suspect also some data loading is disabled which fails some of
> the
> > > > tests
> > > > - hidden dependencies exist from framework / applications to
> > > > specialpurpose.
> > > >
> > > > What does that mean? It means our framework is brittle and depends on
> > > > specialpurpose, and without it being active the system does not run
> > > > properly.
> > > >
> > > > If we are serious about improving the system and making it modular,
> > then
> > > I
> > > > find it very important to start with disabling all specialpurpose
> > > > components or at least having a second build in buildbot for those
> > > > components in isolation of the framework.
> > > >
> > > > I don't think this is a luxury, I highly recommend that we stop the
> > > > specialpurpose components from being active by default to protect and
> > > > isolate the framework and core applications. Actually we need help
> from
> > > > everyone who is willing to help to volunteer in getting a working
> build
> > > > with tests passing while all specialpurpose components are disabled.
> > > >
> > > > Taher Alkhateeb
> > > >
> > > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > > > [hidden email]> wrote:
> > > >
> > > > > Hi Taher, Gil,
> > > > >
> > > > > Exactly my thoughts. Nothing (ethically and technically) should
> force
> > > an
> > > > > user to share his/her/its personal plugins. This assumption must be
> > > part
> > > > of
> > > > > the specifications (assumption as in a theory)
> > > > >
> > > > > Thanks Taher!
> > > > >
> > > > >
> > > > >
> > > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > > > >
> > > > >> Hi Gil,
> > > > >>
> > > > >> Thank you for sharing past experiences. It seems we are tackling
> > > > something
> > > > >> that was attempted multiple times before. I am a bit optimistic
> > though
> > > > >> because having the plugin system integrated into the build system
> > is a
> > > > >> different approach that solves multiple problems I think.
> > > > >>
> > > > >> I would like to note that I think it is okay to use the same
> plugin
> > > > system
> > > > >> even for proprietary customer solutions. In fact I think customers
> > > would
> > > > >> understand it more easily than the concept of hot-deploy. Even if
> > the
> > > > >> solution is for one customer and not intended to be shared you can
> > > still
> > > > >> have a sensible command like ./gradlew installPlugin
> > > > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> > > > >>
> > > > >> Having one solution instead of two solutions I think would unify
> > > efforts
> > > > >> and thinking processes and terminology used. We have only one way
> of
> > > > >> extending OFBiz which is called plugins, and any changes we do
> > happen
> > > in
> > > > >> this unified architecture.
> > > > >>
> > > > >> So ... food for thought.
> > > > >>
> > > > >> Taher Alkhateeb
> > > > >>
> > > > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> > > > [hidden email]>
> > > > >> wrote:
> > > > >>
> > > > >> Hi all,
> > > > >>>
> > > > >>> First, I like the idea of gradle being the plugin solution
> endebbed
> > > > >>> within
> > > > >>> OFBiz.
> > > > >>>
> > > > >>> This could allow OFBiz integrators to share their specific
> > > improvments
> > > > >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons
> or
> > > > >>> Pierre's
> > > > >>> OEM initiatives to name a few).
> > > > >>>
> > > > >>> Then, from what i understand about what Nicolas said, is that
> it'd
> > be
> > > > >>> good
> > > > >>> to keep hot-deploy and create-component tasks for customer
> > projects.
> > > > >>>
> > > > >>> Why not using plugin into customer project ? It is because that
> is
> > a
> > > > >>> private, specific and complete new application using core and
> > plugin
> > > > >>> functionnalities. It has to be separated since it is not a plugin
> > > (not
> > > > >>> intended to be shared). The plugin dependency could be solved
> with
> > a
> > > > >>> build.gradle within the hot-deploy component, checking the
> > > installation
> > > > >>> state of the dependent plugin (and installing if needed).
> > > > >>>
> > > > >>> And last, for your information, Nereide do not use addons
> anymore,
> > > this
> > > > >>> system created more problems than it helped, the original idea
> was
> > > > good,
> > > > >>> but some design flaws did showed up...
> > > > >>> Gil
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> > > > >>>
> > > > >>> 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 think plugins could do that also
> > > > >>>
> > > > >>>
> > > > >>> 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
> > > > >>>
> > > > >>>
> > > > >>> This should be in the specifications indeed, Taher already
> answered
> > > > >>>
> > > > >>>
> > > > >>> We can create the plugins directory, and keep specialpurpose on a
> > > first
> > > > >>> step and move step by step each component present.
> > > > >>>
> > > > >>>
> > > > >>> This is a very important point and we have to be very careful
> about
> > > the
> > > > >>> transition!
> > > > >>>
> > > > >>> Jacques
> > > > >>>
> > > > >>>
> > > > >>> 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 <
> > > > >>> [hidden email]> 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
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >
> > > >
> > >
> >
>

[taher]

Would you be willing to take care of that task Pierre?

On Jul 27, 2016 6:36 PM, "Pierre Smits" <[hidden email]> wrote:

> An issue regarding the move of data up the stack already exists:
> https://issues.apache.org/jira/browse/OFBIZ-7016
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
> > Initially ecommerce was part of the "core" applications, then it was
> moved
> > to specialpurpose because as it it is a "template" for the implementation
> > of an ecommerce store rather than a ready to be used application.
> > I must admit that the same could apply to the other backend applications
> so
> > there is definitely a grey area...
> > For the short term we could consider to move the demo data up the stack.
> >
> > Jacopo
> >
> > On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
> > [hidden email]
> > > wrote:
> >
> > > Hi Jacopo,
> > >
> > > You got it 100% right, it was indeed the ecommerce component. Wow! This
> > > means one of two things should happen, either we move ecommerce as a
> core
> > > application, or we untangle this mess. I'm not very familiar with the
> > > history, is there a reason why ecommerce is a specialpurpose
> application?
> > > it seems to be highly integrated within the framework.
> > >
> > > Taher Alkhateeb
> > >
> > > On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
> > > [hidden email]> wrote:
> > >
> > > > I think that the core reason for the failure is that most of the
> tests
> > > need
> > > > the demo data that is loaded with the ecommerce component; if you
> > disable
> > > > it the data is not loaded.
> > > > Could you please try to enable ecommerce and run them again?
> > > >
> > > > Thanks,
> > > >
> > > > Jacopo
> > > >
> > > > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> > > > [hidden email]
> > > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > In continuation with the above discussion, I just made a little
> > > > experiment
> > > > > which gave me scary results. What did I do?
> > > > >
> > > > > 1 - Disabled all specialpurpose components (except example, to make
> > it
> > > a
> > > > > valid XML file) in specialpurpose/component-load.xml
> > > > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > > > > 3 - Got 100 failing tests
> > > > >
> > > > > So upon investigating a little I believe these tests fail due to
> > > multiple
> > > > > issues:
> > > > > - When we disable specialpurpose, the dependency graph for Jars
> > changes
> > > > and
> > > > > that breaks some system behavior
> > > > > - I suspect also some data loading is disabled which fails some of
> > the
> > > > > tests
> > > > > - hidden dependencies exist from framework / applications to
> > > > > specialpurpose.
> > > > >
> > > > > What does that mean? It means our framework is brittle and depends
> on
> > > > > specialpurpose, and without it being active the system does not run
> > > > > properly.
> > > > >
> > > > > If we are serious about improving the system and making it modular,
> > > then
> > > > I
> > > > > find it very important to start with disabling all specialpurpose
> > > > > components or at least having a second build in buildbot for those
> > > > > components in isolation of the framework.
> > > > >
> > > > > I don't think this is a luxury, I highly recommend that we stop the
> > > > > specialpurpose components from being active by default to protect
> and
> > > > > isolate the framework and core applications. Actually we need help
> > from
> > > > > everyone who is willing to help to volunteer in getting a working
> > build
> > > > > with tests passing while all specialpurpose components are
> disabled.
> > > > >
> > > > > Taher Alkhateeb
> > > > >
> > > > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Hi Taher, Gil,
> > > > > >
> > > > > > Exactly my thoughts. Nothing (ethically and technically) should
> > force
> > > > an
> > > > > > user to share his/her/its personal plugins. This assumption must
> be
> > > > part
> > > > > of
> > > > > > the specifications (assumption as in a theory)
> > > > > >
> > > > > > Thanks Taher!
> > > > > >
> > > > > >
> > > > > >
> > > > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > > > > >
> > > > > >> Hi Gil,
> > > > > >>
> > > > > >> Thank you for sharing past experiences. It seems we are tackling
> > > > > something
> > > > > >> that was attempted multiple times before. I am a bit optimistic
> > > though
> > > > > >> because having the plugin system integrated into the build
> system
> > > is a
> > > > > >> different approach that solves multiple problems I think.
> > > > > >>
> > > > > >> I would like to note that I think it is okay to use the same
> > plugin
> > > > > system
> > > > > >> even for proprietary customer solutions. In fact I think
> customers
> > > > would
> > > > > >> understand it more easily than the concept of hot-deploy. Even
> if
> > > the
> > > > > >> solution is for one customer and not intended to be shared you
> can
> > > > still
> > > > > >> have a sensible command like ./gradlew installPlugin
> > > > > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> > > > > >>
> > > > > >> Having one solution instead of two solutions I think would unify
> > > > efforts
> > > > > >> and thinking processes and terminology used. We have only one
> way
> > of
> > > > > >> extending OFBiz which is called plugins, and any changes we do
> > > happen
> > > > in
> > > > > >> this unified architecture.
> > > > > >>
> > > > > >> So ... food for thought.
> > > > > >>
> > > > > >> Taher Alkhateeb
> > > > > >>
> > > > > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> > > > > [hidden email]>
> > > > > >> wrote:
> > > > > >>
> > > > > >> Hi all,
> > > > > >>>
> > > > > >>> First, I like the idea of gradle being the plugin solution
> > endebbed
> > > > > >>> within
> > > > > >>> OFBiz.
> > > > > >>>
> > > > > >>> This could allow OFBiz integrators to share their specific
> > > > improvments
> > > > > >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons
> > or
> > > > > >>> Pierre's
> > > > > >>> OEM initiatives to name a few).
> > > > > >>>
> > > > > >>> Then, from what i understand about what Nicolas said, is that
> > it'd
> > > be
> > > > > >>> good
> > > > > >>> to keep hot-deploy and create-component tasks for customer
> > > projects.
> > > > > >>>
> > > > > >>> Why not using plugin into customer project ? It is because that
> > is
> > > a
> > > > > >>> private, specific and complete new application using core and
> > > plugin
> > > > > >>> functionnalities. It has to be separated since it is not a
> plugin
> > > > (not
> > > > > >>> intended to be shared). The plugin dependency could be solved
> > with
> > > a
> > > > > >>> build.gradle within the hot-deploy component, checking the
> > > > installation
> > > > > >>> state of the dependent plugin (and installing if needed).
> > > > > >>>
> > > > > >>> And last, for your information, Nereide do not use addons
> > anymore,
> > > > this
> > > > > >>> system created more problems than it helped, the original idea
> > was
> > > > > good,
> > > > > >>> but some design flaws did showed up...
> > > > > >>> Gil
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> > > > > >>>
> > > > > >>> 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 think plugins could do that also
> > > > > >>>
> > > > > >>>
> > > > > >>> 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
> > > > > >>>
> > > > > >>>
> > > > > >>> This should be in the specifications indeed, Taher already
> > answered
> > > > > >>>
> > > > > >>>
> > > > > >>> We can create the plugins directory, and keep specialpurpose
> on a
> > > > first
> > > > > >>> step and move step by step each component present.
> > > > > >>>
> > > > > >>>
> > > > > >>> This is a very important point and we have to be very careful
> > about
> > > > the
> > > > > >>> transition!
> > > > > >>>
> > > > > >>> Jacques
> > > > > >>>
> > > > > >>>
> > > > > >>> 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 <
> > > > > >>> [hidden email]> 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
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[taher]

Hi Pierre and Everyone,

I gather you might be currently preoccupied to work on this JIRA. If my
understanding is correct, then may I suggest to close this JIRA and other
similar JIRAs and allow those interested in implementing the work to create
their own JIRAs for the following reasons:

1- It is confusing to have too many JIRAs open that no one is working on
which is likely to create duplicates.
2- I think it is fair for those who make the effort of designing,
implementing, testing and patching to have their name on the JIRA as the
Reporter as a recognition of their efforts.

Taher Alkhateeb

On Wed, Jul 27, 2016 at 6:39 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Would you be willing to take care of that task Pierre?
>
> On Jul 27, 2016 6:36 PM, "Pierre Smits" <[hidden email]> wrote:
>
>> An issue regarding the move of data up the stack already exists:
>> https://issues.apache.org/jira/browse/OFBIZ-7016
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>> > Initially ecommerce was part of the "core" applications, then it was
>> moved
>> > to specialpurpose because as it it is a "template" for the
>> implementation
>> > of an ecommerce store rather than a ready to be used application.
>> > I must admit that the same could apply to the other backend
>> applications so
>> > there is definitely a grey area...
>> > For the short term we could consider to move the demo data up the stack.
>> >
>> > Jacopo
>> >
>> > On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
>> > [hidden email]
>> > > wrote:
>> >
>> > > Hi Jacopo,
>> > >
>> > > You got it 100% right, it was indeed the ecommerce component. Wow!
>> This
>> > > means one of two things should happen, either we move ecommerce as a
>> core
>> > > application, or we untangle this mess. I'm not very familiar with the
>> > > history, is there a reason why ecommerce is a specialpurpose
>> application?
>> > > it seems to be highly integrated within the framework.
>> > >
>> > > Taher Alkhateeb
>> > >
>> > > On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
>> > > [hidden email]> wrote:
>> > >
>> > > > I think that the core reason for the failure is that most of the
>> tests
>> > > need
>> > > > the demo data that is loaded with the ecommerce component; if you
>> > disable
>> > > > it the data is not loaded.
>> > > > Could you please try to enable ecommerce and run them again?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Jacopo
>> > > >
>> > > > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
>> > > > [hidden email]
>> > > > > wrote:
>> > > >
>> > > > > Hi everyone,
>> > > > >
>> > > > > In continuation with the above discussion, I just made a little
>> > > > experiment
>> > > > > which gave me scary results. What did I do?
>> > > > >
>> > > > > 1 - Disabled all specialpurpose components (except example, to
>> make
>> > it
>> > > a
>> > > > > valid XML file) in specialpurpose/component-load.xml
>> > > > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
>> > > > > 3 - Got 100 failing tests
>> > > > >
>> > > > > So upon investigating a little I believe these tests fail due to
>> > > multiple
>> > > > > issues:
>> > > > > - When we disable specialpurpose, the dependency graph for Jars
>> > changes
>> > > > and
>> > > > > that breaks some system behavior
>> > > > > - I suspect also some data loading is disabled which fails some of
>> > the
>> > > > > tests
>> > > > > - hidden dependencies exist from framework / applications to
>> > > > > specialpurpose.
>> > > > >
>> > > > > What does that mean? It means our framework is brittle and
>> depends on
>> > > > > specialpurpose, and without it being active the system does not
>> run
>> > > > > properly.
>> > > > >
>> > > > > If we are serious about improving the system and making it
>> modular,
>> > > then
>> > > > I
>> > > > > find it very important to start with disabling all specialpurpose
>> > > > > components or at least having a second build in buildbot for those
>> > > > > components in isolation of the framework.
>> > > > >
>> > > > > I don't think this is a luxury, I highly recommend that we stop
>> the
>> > > > > specialpurpose components from being active by default to protect
>> and
>> > > > > isolate the framework and core applications. Actually we need help
>> > from
>> > > > > everyone who is willing to help to volunteer in getting a working
>> > build
>> > > > > with tests passing while all specialpurpose components are
>> disabled.
>> > > > >
>> > > > > Taher Alkhateeb
>> > > > >
>> > > > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
>> > > > > [hidden email]> wrote:
>> > > > >
>> > > > > > Hi Taher, Gil,
>> > > > > >
>> > > > > > Exactly my thoughts. Nothing (ethically and technically) should
>> > force
>> > > > an
>> > > > > > user to share his/her/its personal plugins. This assumption
>> must be
>> > > > part
>> > > > > of
>> > > > > > the specifications (assumption as in a theory)
>> > > > > >
>> > > > > > Thanks Taher!
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
>> > > > > >
>> > > > > >> Hi Gil,
>> > > > > >>
>> > > > > >> Thank you for sharing past experiences. It seems we are
>> tackling
>> > > > > something
>> > > > > >> that was attempted multiple times before. I am a bit optimistic
>> > > though
>> > > > > >> because having the plugin system integrated into the build
>> system
>> > > is a
>> > > > > >> different approach that solves multiple problems I think.
>> > > > > >>
>> > > > > >> I would like to note that I think it is okay to use the same
>> > plugin
>> > > > > system
>> > > > > >> even for proprietary customer solutions. In fact I think
>> customers
>> > > > would
>> > > > > >> understand it more easily than the concept of hot-deploy. Even
>> if
>> > > the
>> > > > > >> solution is for one customer and not intended to be shared you
>> can
>> > > > still
>> > > > > >> have a sensible command like ./gradlew installPlugin
>> > > > > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
>> > > > > >>
>> > > > > >> Having one solution instead of two solutions I think would
>> unify
>> > > > efforts
>> > > > > >> and thinking processes and terminology used. We have only one
>> way
>> > of
>> > > > > >> extending OFBiz which is called plugins, and any changes we do
>> > > happen
>> > > > in
>> > > > > >> this unified architecture.
>> > > > > >>
>> > > > > >> So ... food for thought.
>> > > > > >>
>> > > > > >> Taher Alkhateeb
>> > > > > >>
>> > > > > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
>> > > > > [hidden email]>
>> > > > > >> wrote:
>> > > > > >>
>> > > > > >> Hi all,
>> > > > > >>>
>> > > > > >>> First, I like the idea of gradle being the plugin solution
>> > endebbed
>> > > > > >>> within
>> > > > > >>> OFBiz.
>> > > > > >>>
>> > > > > >>> This could allow OFBiz integrators to share their specific
>> > > > improvments
>> > > > > >>> with a easy to use, OOTB tool (thinking about OfbizExtra
>> addons
>> > or
>> > > > > >>> Pierre's
>> > > > > >>> OEM initiatives to name a few).
>> > > > > >>>
>> > > > > >>> Then, from what i understand about what Nicolas said, is that
>> > it'd
>> > > be
>> > > > > >>> good
>> > > > > >>> to keep hot-deploy and create-component tasks for customer
>> > > projects.
>> > > > > >>>
>> > > > > >>> Why not using plugin into customer project ? It is because
>> that
>> > is
>> > > a
>> > > > > >>> private, specific and complete new application using core and
>> > > plugin
>> > > > > >>> functionnalities. It has to be separated since it is not a
>> plugin
>> > > > (not
>> > > > > >>> intended to be shared). The plugin dependency could be solved
>> > with
>> > > a
>> > > > > >>> build.gradle within the hot-deploy component, checking the
>> > > > installation
>> > > > > >>> state of the dependent plugin (and installing if needed).
>> > > > > >>>
>> > > > > >>> And last, for your information, Nereide do not use addons
>> > anymore,
>> > > > this
>> > > > > >>> system created more problems than it helped, the original idea
>> > was
>> > > > > good,
>> > > > > >>> but some design flaws did showed up...
>> > > > > >>> Gil
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
>> > > > > >>>
>> > > > > >>> 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 think plugins could do that also
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> 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
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> This should be in the specifications indeed, Taher already
>> > answered
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> We can create the plugins directory, and keep specialpurpose
>> on a
>> > > > first
>> > > > > >>> step and move step by step each component present.
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> This is a very important point and we have to be very careful
>> > about
>> > > > the
>> > > > > >>> transition!
>> > > > > >>>
>> > > > > >>> Jacques
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> 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 <
>> > > > > >>> [hidden email]> 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
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>