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

[Sharan-F]

Hi

If we are talking about Jira and ways to handle or improve it for the
project then I did start a discussion thread a few days ago (link below)

https://lists.apache.org/thread.html/61d310a85759c89ca2aa2a18bdca945a9868caf5a1bff2fb72a774d8@%3Cdev.ofbiz.apache.org%3E

It might be good to take this suggestion into that thread rather than
start an off-topic discussion here.

Thanks
Sharan

On 28/07/16 08:54, Taher Alkhateeb wrote:

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

[taher]

Great, I'll continue discussion over there referring to this conversation.

On Thu, Jul 28, 2016 at 10:03 AM, Sharan Foga <[hidden email]> wrote:

> Hi
>
> If we are talking about Jira and ways to handle or improve it for the
> project then I did start a discussion thread a few days ago (link below)
>
>
> https://lists.apache.org/thread.html/61d310a85759c89ca2aa2a18bdca945a9868caf5a1bff2fb72a774d8@%3Cdev.ofbiz.apache.org%3E
>
> It might be good to take this suggestion into that thread rather than
> start an off-topic discussion here.
>
> Thanks
> Sharan
>
>
> On 28/07/16 08:54, Taher Alkhateeb wrote:
>
>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>