[Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux]

We know you like visual graphics ;) And it's a good idea!

Jacques

Le 24/11/2015 15:40, Ron Wheeler a écrit :

> Would it be possible create a graphic in the docs identifying what overrides what as you find this out?
> A description would be great but at least a visual summary would help the next person.
>
> Ron
>
> On 24/11/2015 8:31 AM, Jacques Le Roux wrote:
>> Yes I see, as suggested by Nicolas. But it seems not obvious for a non technical person,  and they are often those who assess the product by simply
>> running the fasted and easiest ways (I do that also with other software, who don't? ;))
>> Like "Start" section at http://ofbiz.apache.org/download.html and others alike in wiki. Unfortunately you can only make 1 1st impression. Of
>> course, we possibly could give them an UI for that but we should at least change (all) our documentation.
>>
>> And even if we agree on this, the main part of the work remains: some components should not be "commented out".
>>
>> 1. AFAIK example and exampleext does not override anything and they are useful (at least to me), notably in official demo.
>> 2. Obviously, as it was in R13.07, ecommerce. But not sure the ecommerce component does not override applications...
>> 3. The POS is not concerned: not used in official demos, does not override anything.
>> 4. I wonder about the WepPos, does it overrides something, I don't think so but not sure
>> 5. Several persons spoke about the project manager, not sure it overrides applications.
>>
>> So the 1st step should be to clearly identify which components are concerned.
>>
>> Jacopo said <<the default demo of OFBiz will only showcase the more specialized behaviors>> We could have all released demos not using some
>> specialpurpose components but trunk with all? It's bleeding edge after all.
>>
>> Jacques
>>
>> Le 21/11/2015 13:07, [hidden email] a écrit :
>>> Hi Jacques,
>>>
>>> what about a parameter using -D for the build script. we can also do something programmatic in the ./tools directory.
>>>
>>> Regards,
>>> --
>>>
>>> Taher Alkhateeb
>>>
>>>> On Nov 21, 2015, at 12:53 PM, Jacques Le Roux<[hidden email]>  wrote:
>>>>
>>>> I'd veto something which would blindly applies to all specialpurpose components, see my last post about that
>>>>
>>>> Jacques
>>>>
>>>> Le 21/11/2015 09:22, Jacopo Cappellato a écrit :
>>>>> Taher,
>>>>>
>>>>> I like your proposal; in fact this feature would be useful not only for
>>>>> automated deployments/tests but also to end users to easily enable the
>>>>> components they like.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> On Sat, Nov 21, 2015 at 8:53 AM,<[hidden email]>  wrote:
>>>>>>
>>>>>> Hi Jacopo,
>>>>>>
>>>>>> I would make a distinction between two things: a) preserve what exists and
>>>>>> b) prepare for the future.
>>>>>>
>>>>>> Doubtless what you are saying below makes perfect sense as a design
>>>>>> decision to allow for better future developments. I am concerned however
>>>>>> with what currently exists in specialpurpose. Specifically, I worry about
>>>>>> unit tests and Java Source code for framework integration. Changes we make
>>>>>> to the framework now needs to be followed up closely and we need to
>>>>>> manually enable, test and re-disable the specialpurpose components to
>>>>>> ensure continuous compatibility with trunk. Can we at least have a
>>>>>> modification in build.xml to enable / disable specialpurpose so that the
>>>>>> buildbot would continually test against specialpurpose?
>>>>>>
>>>>>> If you agree then I can try to write something to that effect in build.xml
>>>>>> at least to keep the code live in specialpurpose.
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>>> On Nov 19, 2015, at 4:36 PM, Jacopo Cappellato <
>>>>>>> [hidden email]> wrote:
>>>>>>> I was actually thinking to Birt as an example of this behavior: but in
>>>>>> the
>>>>>>> future we may add other special purpose applications that need to
>>>>>> override
>>>>>>> applications screens (in fact overriding screens and other artifacts to
>>>>>>> specialize them is a best practice in OFBiz) and the problem will happen
>>>>>>> again if we keep them all enabled.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>> Could we list, apart the well known Birt issue, special components which
>>>>>>>> are overriding main applications?
>>>>>>>>
>>>>>>>> Then depending on cases we could be more surgical...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> I agree with Taher when he says that we should strive to move small
>>>>>> steps
>>>>>>>>> in the direction of having a lean lightweight framework with pluggable
>>>>>>>>> components.
>>>>>>>>> But I think that Nicolas' proposal is actually one of these steps.
>>>>>>>>> The fact that currently some of our specialized components are
>>>>>> overriding
>>>>>>>>> the more generic behavior of other components (e.g. the ones under
>>>>>>>>> "applications") is a problem that we have to fix asap.
>>>>>>>>> Otherwise the default demo of OFBiz will only showcase the more
>>>>>>>>> specialized
>>>>>>>>> behaviors; for example, if tomorrow we will add a new special purpose
>>>>>>>>> component for a niche industry, that will override the application
>>>>>> screens
>>>>>>>>> with industry specific ones from that day on all OFBiz users that will
>>>>>>>>> download and run OFBiz will have the impression that OFBiz was designed
>>>>>>>>> for
>>>>>>>>> one specific industry only.
>>>>>>>>> Nicolas' proposal addresses this issue and still leaves the ability to
>>>>>> the
>>>>>>>>> interested users to manually enable the components they need.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
>>>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>> Hi Nicolas,
>>>>>>>>>>
>>>>>>>>>> I think If your finger hurts you don't cut it off. The project has too
>>>>>>>>>> many
>>>>>>>>>> pages, documentations, email threads and time dedicated to the special
>>>>>>>>>> purpose components. They existed for a long, long time in the history
>>>>>> of
>>>>>>>>>> OFBiz.
>>>>>>>>>>
>>>>>>>>>> Some attempts were made in the past to reduce the size of the
>>>>>> framework
>>>>>>>>>> and
>>>>>>>>>> release 13.07 is a prime example of these attempts which failed IMHO.
>>>>>>>>>> This
>>>>>>>>>> is a reason why, for example, a rewrite of the framework is being
>>>>>>>>>> discussed
>>>>>>>>>> in the community.
>>>>>>>>>>
>>>>>>>>>> I would suggest to you that to get really lean and clean, we need to
>>>>>> work
>>>>>>>>>> on the root of the problem which is the design of the framework and
>>>>>> its
>>>>>>>>>> architecture. We need a _plugin_ implementation that achieves _loose
>>>>>>>>>> coupling_ of the components in a way that sustains the quality of the
>>>>>>>>>> code
>>>>>>>>>> while at the same time allowing a small framework core to thrive.
>>>>>> Take a
>>>>>>>>>> look at this thread <
>>>>>> http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>>>>>>>> in
>>>>>>>>>> which we discussed this issue and suggested one of several strategies.
>>>>>>>>>> There are other threads which I cannot recall at the moment.
>>>>>>>>>>
>>>>>>>>>> For the record, I totally agree with keeping a small core and a lean
>>>>>>>>>> framework, It's how we get there that I'm worried about and I would
>>>>>>>>>> suggest
>>>>>>>>>> to you that we do this in a well thought out and gradual process.
>>>>>>>>>>
>>>>>>>>>> My 2 cents
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
>>>>>>>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Le 10/11/2015 05:54,[hidden email] a écrit :
>>>>>>>>>>> This topic was heavily discussed in the past and I think a solution
>>>>>> like
>>>>>>>>>>>> turning off the components is very quick indeed but not ideal.
>>>>>>>>>>>>
>>>>>>>>>>>> Completely, I'm sure a better ideal exist but difficult to reach.
>>>>>>>>>>> A second step, easy to reach would be enable a specialpurpose
>>>>>> directly
>>>>>>>>>>> by
>>>>>>>>>>> an ant target :
>>>>>>>>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>>>>>>>>> or
>>>>>>>>>>> $ ant load-component -D"components=ecommerce projectmgr myportal"
>>>>>>>>>>> load-demo start
>>>>>>>>>>>
>>>>>>>>>>> This help beginner through easy command line to copy/past from
>>>>>>>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>>>>>>>
>>>>>>>>>>> Nicolas
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
>>
>
>

[Ron Wheeler]

The old joke:

Why is it more important for women to be beautiful than smart?
Because men see better than they think!


If you need any help, let me know.

Ron

On 24/11/2015 10:37 AM, Jacques Le Roux wrote:

> We know you like visual graphics ;) And it's a good idea!
>
> Jacques
>
> Le 24/11/2015 15:40, Ron Wheeler a écrit :
>> Would it be possible create a graphic in the docs identifying what
>> overrides what as you find this out?
>> A description would be great but at least a visual summary would help
>> the next person.
>>
>> Ron
>>
>> On 24/11/2015 8:31 AM, Jacques Le Roux wrote:
>>> Yes I see, as suggested by Nicolas. But it seems not obvious for a
>>> non technical person,  and they are often those who assess the
>>> product by simply running the fasted and easiest ways (I do that
>>> also with other software, who don't? ;))
>>> Like "Start" section at http://ofbiz.apache.org/download.html and
>>> others alike in wiki. Unfortunately you can only make 1 1st
>>> impression. Of course, we possibly could give them an UI for that
>>> but we should at least change (all) our documentation.
>>>
>>> And even if we agree on this, the main part of the work remains:
>>> some components should not be "commented out".
>>>
>>> 1. AFAIK example and exampleext does not override anything and they
>>> are useful (at least to me), notably in official demo.
>>> 2. Obviously, as it was in R13.07, ecommerce. But not sure the
>>> ecommerce component does not override applications...
>>> 3. The POS is not concerned: not used in official demos, does not
>>> override anything.
>>> 4. I wonder about the WepPos, does it overrides something, I don't
>>> think so but not sure
>>> 5. Several persons spoke about the project manager, not sure it
>>> overrides applications.
>>>
>>> So the 1st step should be to clearly identify which components are
>>> concerned.
>>>
>>> Jacopo said <<the default demo of OFBiz will only showcase the more
>>> specialized behaviors>> We could have all released demos not using
>>> some specialpurpose components but trunk with all? It's bleeding
>>> edge after all.
>>>
>>> Jacques
>>>
>>> Le 21/11/2015 13:07, [hidden email] a écrit :
>>>> Hi Jacques,
>>>>
>>>> what about a parameter using -D for the build script. we can also
>>>> do something programmatic in the ./tools directory.
>>>>
>>>> Regards,
>>>> --
>>>>
>>>> Taher Alkhateeb
>>>>
>>>>> On Nov 21, 2015, at 12:53 PM, Jacques Le
>>>>> Roux<[hidden email]> wrote:
>>>>>
>>>>> I'd veto something which would blindly applies to all
>>>>> specialpurpose components, see my last post about that
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 21/11/2015 09:22, Jacopo Cappellato a écrit :
>>>>>> Taher,
>>>>>>
>>>>>> I like your proposal; in fact this feature would be useful not
>>>>>> only for
>>>>>> automated deployments/tests but also to end users to easily
>>>>>> enable the
>>>>>> components they like.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>> On Sat, Nov 21, 2015 at 8:53 AM,<[hidden email]>  
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Jacopo,
>>>>>>>
>>>>>>> I would make a distinction between two things: a) preserve what
>>>>>>> exists and
>>>>>>> b) prepare for the future.
>>>>>>>
>>>>>>> Doubtless what you are saying below makes perfect sense as a design
>>>>>>> decision to allow for better future developments. I am concerned
>>>>>>> however
>>>>>>> with what currently exists in specialpurpose. Specifically, I
>>>>>>> worry about
>>>>>>> unit tests and Java Source code for framework integration.
>>>>>>> Changes we make
>>>>>>> to the framework now needs to be followed up closely and we need to
>>>>>>> manually enable, test and re-disable the specialpurpose
>>>>>>> components to
>>>>>>> ensure continuous compatibility with trunk. Can we at least have a
>>>>>>> modification in build.xml to enable / disable specialpurpose so
>>>>>>> that the
>>>>>>> buildbot would continually test against specialpurpose?
>>>>>>>
>>>>>>> If you agree then I can try to write something to that effect in
>>>>>>> build.xml
>>>>>>> at least to keep the code live in specialpurpose.
>>>>>>>
>>>>>>> Regards,
>>>>>>> --
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>>>> On Nov 19, 2015, at 4:36 PM, Jacopo Cappellato <
>>>>>>>> [hidden email]> wrote:
>>>>>>>> I was actually thinking to Birt as an example of this behavior:
>>>>>>>> but in
>>>>>>> the
>>>>>>>> future we may add other special purpose applications that need to
>>>>>>> override
>>>>>>>> applications screens (in fact overriding screens and other
>>>>>>>> artifacts to
>>>>>>>> specialize them is a best practice in OFBiz) and the problem
>>>>>>>> will happen
>>>>>>>> again if we keep them all enabled.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>>> Could we list, apart the well known Birt issue, special
>>>>>>>>> components which
>>>>>>>>> are overriding main applications?
>>>>>>>>>
>>>>>>>>> Then depending on cases we could be more surgical...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>>>>>>>>>
>>>>>>>>>> I agree with Taher when he says that we should strive to move
>>>>>>>>>> small
>>>>>>> steps
>>>>>>>>>> in the direction of having a lean lightweight framework with
>>>>>>>>>> pluggable
>>>>>>>>>> components.
>>>>>>>>>> But I think that Nicolas' proposal is actually one of these
>>>>>>>>>> steps.
>>>>>>>>>> The fact that currently some of our specialized components are
>>>>>>> overriding
>>>>>>>>>> the more generic behavior of other components (e.g. the ones
>>>>>>>>>> under
>>>>>>>>>> "applications") is a problem that we have to fix asap.
>>>>>>>>>> Otherwise the default demo of OFBiz will only showcase the more
>>>>>>>>>> specialized
>>>>>>>>>> behaviors; for example, if tomorrow we will add a new special
>>>>>>>>>> purpose
>>>>>>>>>> component for a niche industry, that will override the
>>>>>>>>>> application
>>>>>>> screens
>>>>>>>>>> with industry specific ones from that day on all OFBiz users
>>>>>>>>>> that will
>>>>>>>>>> download and run OFBiz will have the impression that OFBiz
>>>>>>>>>> was designed
>>>>>>>>>> for
>>>>>>>>>> one specific industry only.
>>>>>>>>>> Nicolas' proposal addresses this issue and still leaves the
>>>>>>>>>> ability to
>>>>>>> the
>>>>>>>>>> interested users to manually enable the components they need.
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
>>>>>>>>>> [hidden email]
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Nicolas,
>>>>>>>>>>>
>>>>>>>>>>> I think If your finger hurts you don't cut it off. The
>>>>>>>>>>> project has too
>>>>>>>>>>> many
>>>>>>>>>>> pages, documentations, email threads and time dedicated to
>>>>>>>>>>> the special
>>>>>>>>>>> purpose components. They existed for a long, long time in
>>>>>>>>>>> the history
>>>>>>> of
>>>>>>>>>>> OFBiz.
>>>>>>>>>>>
>>>>>>>>>>> Some attempts were made in the past to reduce the size of the
>>>>>>> framework
>>>>>>>>>>> and
>>>>>>>>>>> release 13.07 is a prime example of these attempts which
>>>>>>>>>>> failed IMHO.
>>>>>>>>>>> This
>>>>>>>>>>> is a reason why, for example, a rewrite of the framework is
>>>>>>>>>>> being
>>>>>>>>>>> discussed
>>>>>>>>>>> in the community.
>>>>>>>>>>>
>>>>>>>>>>> I would suggest to you that to get really lean and clean, we
>>>>>>>>>>> need to
>>>>>>> work
>>>>>>>>>>> on the root of the problem which is the design of the
>>>>>>>>>>> framework and
>>>>>>> its
>>>>>>>>>>> architecture. We need a _plugin_ implementation that
>>>>>>>>>>> achieves _loose
>>>>>>>>>>> coupling_ of the components in a way that sustains the
>>>>>>>>>>> quality of the
>>>>>>>>>>> code
>>>>>>>>>>> while at the same time allowing a small framework core to
>>>>>>>>>>> thrive.
>>>>>>> Take a
>>>>>>>>>>> look at this thread <
>>>>>>> http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>>>>>>>>> in
>>>>>>>>>>> which we discussed this issue and suggested one of several
>>>>>>>>>>> strategies.
>>>>>>>>>>> There are other threads which I cannot recall at the moment.
>>>>>>>>>>>
>>>>>>>>>>> For the record, I totally agree with keeping a small core
>>>>>>>>>>> and a lean
>>>>>>>>>>> framework, It's how we get there that I'm worried about and
>>>>>>>>>>> I would
>>>>>>>>>>> suggest
>>>>>>>>>>> to you that we do this in a well thought out and gradual
>>>>>>>>>>> process.
>>>>>>>>>>>
>>>>>>>>>>> My 2 cents
>>>>>>>>>>>
>>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
>>>>>>>>>>> [hidden email]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Le 10/11/2015 05:54,[hidden email] a écrit :
>>>>>>>>>>>> This topic was heavily discussed in the past and I think a
>>>>>>>>>>>> solution
>>>>>>> like
>>>>>>>>>>>>> turning off the components is very quick indeed but not
>>>>>>>>>>>>> ideal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Completely, I'm sure a better ideal exist but difficult to
>>>>>>>>>>>>> reach.
>>>>>>>>>>>> A second step, easy to reach would be enable a specialpurpose
>>>>>>> directly
>>>>>>>>>>>> by
>>>>>>>>>>>> an ant target :
>>>>>>>>>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>>>>>>>>>> or
>>>>>>>>>>>> $ ant load-component -D"components=ecommerce projectmgr
>>>>>>>>>>>> myportal"
>>>>>>>>>>>> load-demo start
>>>>>>>>>>>>
>>>>>>>>>>>> This help beginner through easy command line to copy/past from
>>>>>>>>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>>>>>>>>
>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>>
>>
>>
>

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

[Nicolas Malin-2]

Le 19/11/2015 11:45, Jacques Le Roux a écrit :
> Could we list, apart the well known Birt issue, special components
> which are overriding main applications?
Directly by memory, the scrum components has defined new seca on cust
request to send email that break the standard customer request system

An other where I failed,  used service findProductsById instead of
findProductById, the first from hhfacilty and the second from catalog.
And want you start your hot-deploy component without specialpurpose ...
paff ! :)

The problem will appear in the future for sure if we load new
components, it's impossible to test all process in OFBiz to ensure no
regression.

I've been thinking about that with the idea to load magento component on
specialpurpose, and I continued the thinking on the other win.

Nicolas

>
> Then depending on cases we could be more surgical...
>
> Jacques
>
> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>> I agree with Taher when he says that we should strive to move small
>> steps
>> in the direction of having a lean lightweight framework with pluggable
>> components.
>> But I think that Nicolas' proposal is actually one of these steps.
>> The fact that currently some of our specialized components are
>> overriding
>> the more generic behavior of other components (e.g. the ones under
>> "applications") is a problem that we have to fix asap.
>> Otherwise the default demo of OFBiz will only showcase the more
>> specialized
>> behaviors; for example, if tomorrow we will add a new special purpose
>> component for a niche industry, that will override the application
>> screens
>> with industry specific ones from that day on all OFBiz users that will
>> download and run OFBiz will have the impression that OFBiz was
>> designed for
>> one specific industry only.
>> Nicolas' proposal addresses this issue and still leaves the ability
>> to the
>> interested users to manually enable the components they need.
>>
>> Jacopo
>>
>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb
>> <[hidden email]
>>> wrote:
>>> Hi Nicolas,
>>>
>>> I think If your finger hurts you don't cut it off. The project has
>>> too many
>>> pages, documentations, email threads and time dedicated to the special
>>> purpose components. They existed for a long, long time in the
>>> history of
>>> OFBiz.
>>>
>>> Some attempts were made in the past to reduce the size of the
>>> framework and
>>> release 13.07 is a prime example of these attempts which failed
>>> IMHO. This
>>> is a reason why, for example, a rewrite of the framework is being
>>> discussed
>>> in the community.
>>>
>>> I would suggest to you that to get really lean and clean, we need to
>>> work
>>> on the root of the problem which is the design of the framework and its
>>> architecture. We need a _plugin_ implementation that achieves _loose
>>> coupling_ of the components in a way that sustains the quality of
>>> the code
>>> while at the same time allowing a small framework core to thrive.
>>> Take a
>>> look at this thread
>>> <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff> in
>>> which we discussed this issue and suggested one of several strategies.
>>> There are other threads which I cannot recall at the moment.
>>>
>>> For the record, I totally agree with keeping a small core and a lean
>>> framework, It's how we get there that I'm worried about and I would
>>> suggest
>>> to you that we do this in a well thought out and gradual process.
>>>
>>> My 2 cents
>>>
>>> Taher Alkhateeb
>>>
>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin
>>> <[hidden email]>
>>> wrote:
>>>
>>>> Le 10/11/2015 05:54, [hidden email] a écrit :
>>>>
>>>>> This topic was heavily discussed in the past and I think a
>>>>> solution like
>>>>> turning off the components is very quick indeed but not ideal.
>>>>>
>>>> Completely, I'm sure a better ideal exist but difficult to reach.
>>>>
>>>> A second step, easy to reach would be enable a specialpurpose
>>>> directly by
>>>> an ant target :
>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>> or
>>>> $ ant load-component -D"components=ecommerce projectmgr myportal"
>>>> load-demo start
>>>>
>>>> This help beginner through easy command line to copy/past from
>>>> documentation or expert by scripting to configure ofbiz.
>>>>
>>>> Nicolas
>>>>
>>>>

[Nicolas Malin-2]

Jacques I understand.

We can find a compromise if each specialpurpose components would be
identify by meta-data like : demo, util, contrib, buisness specific to
help the end user to load ofbiz with some component like he can load the
data with load-seed or load-demo.

But it's a second big step

Le 24/11/2015 14:31, Jacques Le Roux a écrit :

> Yes I see, as suggested by Nicolas. But it seems not obvious for a non
> technical person,  and they are often those who assess the product by
> simply running the fasted and easiest ways (I do that also with other
> software, who don't? ;))
> Like "Start" section at http://ofbiz.apache.org/download.html and
> others alike in wiki. Unfortunately you can only make 1 1st
> impression. Of course, we possibly could give them an UI for that but
> we should at least change (all) our documentation.
>
> And even if we agree on this, the main part of the work remains: some
> components should not be "commented out".
>
> 1. AFAIK example and exampleext does not override anything and they
> are useful (at least to me), notably in official demo.
> 2. Obviously, as it was in R13.07, ecommerce. But not sure the
> ecommerce component does not override applications...
> 3. The POS is not concerned: not used in official demos, does not
> override anything.
> 4. I wonder about the WepPos, does it overrides something, I don't
> think so but not sure
> 5. Several persons spoke about the project manager, not sure it
> overrides applications.
>
> So the 1st step should be to clearly identify which components are
> concerned.

ok :) can you give your preference for this 3 cases :
  * source code
  * official demo
  * download release

Nicolas

>
>
> Jacopo said <<the default demo of OFBiz will only showcase the more
> specialized behaviors>> We could have all released demos not using
> some specialpurpose components but trunk with all? It's bleeding edge
> after all.
>
> Jacques
>
> Le 21/11/2015 13:07, [hidden email] a écrit :
>> Hi Jacques,
>>
>> what about a parameter using -D for the build script. we can also do
>> something programmatic in the ./tools directory.
>>
>> Regards,
>> --
>>
>> Taher Alkhateeb
>>
>>> On Nov 21, 2015, at 12:53 PM, Jacques Le
>>> Roux<[hidden email]>  wrote:
>>>
>>> I'd veto something which would blindly applies to all specialpurpose
>>> components, see my last post about that
>>>
>>> Jacques
>>>
>>> Le 21/11/2015 09:22, Jacopo Cappellato a écrit :
>>>> Taher,
>>>>
>>>> I like your proposal; in fact this feature would be useful not only
>>>> for
>>>> automated deployments/tests but also to end users to easily enable the
>>>> components they like.
>>>>
>>>> Jacopo
>>>>
>>>>> On Sat, Nov 21, 2015 at 8:53 AM,<[hidden email]>  wrote:
>>>>>
>>>>> Hi Jacopo,
>>>>>
>>>>> I would make a distinction between two things: a) preserve what
>>>>> exists and
>>>>> b) prepare for the future.
>>>>>
>>>>> Doubtless what you are saying below makes perfect sense as a design
>>>>> decision to allow for better future developments. I am concerned
>>>>> however
>>>>> with what currently exists in specialpurpose. Specifically, I
>>>>> worry about
>>>>> unit tests and Java Source code for framework integration. Changes
>>>>> we make
>>>>> to the framework now needs to be followed up closely and we need to
>>>>> manually enable, test and re-disable the specialpurpose components to
>>>>> ensure continuous compatibility with trunk. Can we at least have a
>>>>> modification in build.xml to enable / disable specialpurpose so
>>>>> that the
>>>>> buildbot would continually test against specialpurpose?
>>>>>
>>>>> If you agree then I can try to write something to that effect in
>>>>> build.xml
>>>>> at least to keep the code live in specialpurpose.
>>>>>
>>>>> Regards,
>>>>> --
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>>>> On Nov 19, 2015, at 4:36 PM, Jacopo Cappellato <
>>>>>> [hidden email]> wrote:
>>>>>> I was actually thinking to Birt as an example of this behavior:
>>>>>> but in
>>>>> the
>>>>>> future we may add other special purpose applications that need to
>>>>> override
>>>>>> applications screens (in fact overriding screens and other
>>>>>> artifacts to
>>>>>> specialize them is a best practice in OFBiz) and the problem will
>>>>>> happen
>>>>>> again if we keep them all enabled.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> Could we list, apart the well known Birt issue, special
>>>>>>> components which
>>>>>>> are overriding main applications?
>>>>>>>
>>>>>>> Then depending on cases we could be more surgical...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>>>>>>>
>>>>>>>> I agree with Taher when he says that we should strive to move
>>>>>>>> small
>>>>> steps
>>>>>>>> in the direction of having a lean lightweight framework with
>>>>>>>> pluggable
>>>>>>>> components.
>>>>>>>> But I think that Nicolas' proposal is actually one of these steps.
>>>>>>>> The fact that currently some of our specialized components are
>>>>> overriding
>>>>>>>> the more generic behavior of other components (e.g. the ones under
>>>>>>>> "applications") is a problem that we have to fix asap.
>>>>>>>> Otherwise the default demo of OFBiz will only showcase the more
>>>>>>>> specialized
>>>>>>>> behaviors; for example, if tomorrow we will add a new special
>>>>>>>> purpose
>>>>>>>> component for a niche industry, that will override the application
>>>>> screens
>>>>>>>> with industry specific ones from that day on all OFBiz users
>>>>>>>> that will
>>>>>>>> download and run OFBiz will have the impression that OFBiz was
>>>>>>>> designed
>>>>>>>> for
>>>>>>>> one specific industry only.
>>>>>>>> Nicolas' proposal addresses this issue and still leaves the
>>>>>>>> ability to
>>>>> the
>>>>>>>> interested users to manually enable the components they need.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
>>>>>>>> [hidden email]
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>> Hi Nicolas,
>>>>>>>>>
>>>>>>>>> I think If your finger hurts you don't cut it off. The project
>>>>>>>>> has too
>>>>>>>>> many
>>>>>>>>> pages, documentations, email threads and time dedicated to the
>>>>>>>>> special
>>>>>>>>> purpose components. They existed for a long, long time in the
>>>>>>>>> history
>>>>> of
>>>>>>>>> OFBiz.
>>>>>>>>>
>>>>>>>>> Some attempts were made in the past to reduce the size of the
>>>>> framework
>>>>>>>>> and
>>>>>>>>> release 13.07 is a prime example of these attempts which
>>>>>>>>> failed IMHO.
>>>>>>>>> This
>>>>>>>>> is a reason why, for example, a rewrite of the framework is being
>>>>>>>>> discussed
>>>>>>>>> in the community.
>>>>>>>>>
>>>>>>>>> I would suggest to you that to get really lean and clean, we
>>>>>>>>> need to
>>>>> work
>>>>>>>>> on the root of the problem which is the design of the
>>>>>>>>> framework and
>>>>> its
>>>>>>>>> architecture. We need a _plugin_ implementation that achieves
>>>>>>>>> _loose
>>>>>>>>> coupling_ of the components in a way that sustains the quality
>>>>>>>>> of the
>>>>>>>>> code
>>>>>>>>> while at the same time allowing a small framework core to thrive.
>>>>> Take a
>>>>>>>>> look at this thread <
>>>>> http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>>>>>>> in
>>>>>>>>> which we discussed this issue and suggested one of several
>>>>>>>>> strategies.
>>>>>>>>> There are other threads which I cannot recall at the moment.
>>>>>>>>>
>>>>>>>>> For the record, I totally agree with keeping a small core and
>>>>>>>>> a lean
>>>>>>>>> framework, It's how we get there that I'm worried about and I
>>>>>>>>> would
>>>>>>>>> suggest
>>>>>>>>> to you that we do this in a well thought out and gradual process.
>>>>>>>>>
>>>>>>>>> My 2 cents
>>>>>>>>>
>>>>>>>>> Taher Alkhateeb
>>>>>>>>>
>>>>>>>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
>>>>>>>>> [hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Le 10/11/2015 05:54,[hidden email]  a écrit :
>>>>>>>>>> This topic was heavily discussed in the past and I think a
>>>>>>>>>> solution
>>>>> like
>>>>>>>>>>> turning off the components is very quick indeed but not ideal.
>>>>>>>>>>>
>>>>>>>>>>> Completely, I'm sure a better ideal exist but difficult to
>>>>>>>>>>> reach.
>>>>>>>>>> A second step, easy to reach would be enable a specialpurpose
>>>>> directly
>>>>>>>>>> by
>>>>>>>>>> an ant target :
>>>>>>>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>>>>>>>> or
>>>>>>>>>> $ ant load-component -D"components=ecommerce projectmgr
>>>>>>>>>> myportal"
>>>>>>>>>> load-demo start
>>>>>>>>>>
>>>>>>>>>> This help beginner through easy command line to copy/past from
>>>>>>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>>>>>>
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
>

[Pierre Smits]

I suggest to fix such with separate JIRA issues for each.

Best regards,

Pierre Smits

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

On Thu, Dec 3, 2015 at 11:05 PM, Nicolas Malin <[hidden email]>
wrote:

> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>
>> Could we list, apart the well known Birt issue, special components which
>> are overriding main applications?
>>
> Directly by memory, the scrum components has defined new seca on cust
> request to send email that break the standard customer request system
>
> An other where I failed,  used service findProductsById instead of
> findProductById, the first from hhfacilty and the second from catalog. And
> want you start your hot-deploy component without specialpurpose ... paff !
> :)
>
> The problem will appear in the future for sure if we load new components,
> it's impossible to test all process in OFBiz to ensure no regression.
>
> I've been thinking about that with the idea to load magento component on
> specialpurpose, and I continued the thinking on the other win.
>
> Nicolas
>
>
>
>> Then depending on cases we could be more surgical...
>>
>> Jacques
>>
>> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>>
>>> I agree with Taher when he says that we should strive to move small steps
>>> in the direction of having a lean lightweight framework with pluggable
>>> components.
>>> But I think that Nicolas' proposal is actually one of these steps.
>>> The fact that currently some of our specialized components are overriding
>>> the more generic behavior of other components (e.g. the ones under
>>> "applications") is a problem that we have to fix asap.
>>> Otherwise the default demo of OFBiz will only showcase the more
>>> specialized
>>> behaviors; for example, if tomorrow we will add a new special purpose
>>> component for a niche industry, that will override the application
>>> screens
>>> with industry specific ones from that day on all OFBiz users that will
>>> download and run OFBiz will have the impression that OFBiz was designed
>>> for
>>> one specific industry only.
>>> Nicolas' proposal addresses this issue and still leaves the ability to
>>> the
>>> interested users to manually enable the components they need.
>>>
>>> Jacopo
>>>
>>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
>>> [hidden email]
>>>
>>>> wrote:
>>>> Hi Nicolas,
>>>>
>>>> I think If your finger hurts you don't cut it off. The project has too
>>>> many
>>>> pages, documentations, email threads and time dedicated to the special
>>>> purpose components. They existed for a long, long time in the history of
>>>> OFBiz.
>>>>
>>>> Some attempts were made in the past to reduce the size of the framework
>>>> and
>>>> release 13.07 is a prime example of these attempts which failed IMHO.
>>>> This
>>>> is a reason why, for example, a rewrite of the framework is being
>>>> discussed
>>>> in the community.
>>>>
>>>> I would suggest to you that to get really lean and clean, we need to
>>>> work
>>>> on the root of the problem which is the design of the framework and its
>>>> architecture. We need a _plugin_ implementation that achieves _loose
>>>> coupling_ of the components in a way that sustains the quality of the
>>>> code
>>>> while at the same time allowing a small framework core to thrive. Take a
>>>> look at this thread <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>> in
>>>> which we discussed this issue and suggested one of several strategies.
>>>> There are other threads which I cannot recall at the moment.
>>>>
>>>> For the record, I totally agree with keeping a small core and a lean
>>>> framework, It's how we get there that I'm worried about and I would
>>>> suggest
>>>> to you that we do this in a well thought out and gradual process.
>>>>
>>>> My 2 cents
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
>>>> [hidden email]>
>>>> wrote:
>>>>
>>>> Le 10/11/2015 05:54, [hidden email] a écrit :
>>>>>
>>>>> This topic was heavily discussed in the past and I think a solution
>>>>>> like
>>>>>> turning off the components is very quick indeed but not ideal.
>>>>>>
>>>>>> Completely, I'm sure a better ideal exist but difficult to reach.
>>>>>
>>>>> A second step, easy to reach would be enable a specialpurpose directly
>>>>> by
>>>>> an ant target :
>>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>>> or
>>>>> $ ant load-component -D"components=ecommerce projectmgr myportal"
>>>>> load-demo start
>>>>>
>>>>> This help beginner through easy command line to copy/past from
>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>>

[Jacques Le Roux]

Le 05/12/2015 13:47, Pierre Smits a écrit :

> I suggest to fix such with separate JIRA issues for each.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Dec 3, 2015 at 11:05 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>>
>>> Could we list, apart the well known Birt issue, special components which
>>> are overriding main applications?
>>>
>> Directly by memory, the scrum components has defined new seca on cust
>> request to send email that break the standard customer request system
>>
>> An other where I failed,  used service findProductsById instead of
>> findProductById, the first from hhfacilty and the second from catalog. And
>> want you start your hot-deploy component without specialpurpose ... paff !
>> :)

Thanks for these points Nicolas, I agree with Pierre suggestion.

For instance does really the hhfacilty findProductById service needs to be named the same than in product? Etc.

>>
>> The problem will appear in the future for sure if we load new components,
>> it's impossible to test all process in OFBiz to ensure no regression.

I agree, the power of overriding comes with its drawbacks...


Jacques

>>
>> I've been thinking about that with the idea to load magento component on
>> specialpurpose, and I continued the thinking on the other win.
>>
>> Nicolas
>>
>>
>>
>>> Then depending on cases we could be more surgical...
>>>
>>> Jacques
>>>
>>> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>>>
>>>> I agree with Taher when he says that we should strive to move small steps
>>>> in the direction of having a lean lightweight framework with pluggable
>>>> components.
>>>> But I think that Nicolas' proposal is actually one of these steps.
>>>> The fact that currently some of our specialized components are overriding
>>>> the more generic behavior of other components (e.g. the ones under
>>>> "applications") is a problem that we have to fix asap.
>>>> Otherwise the default demo of OFBiz will only showcase the more
>>>> specialized
>>>> behaviors; for example, if tomorrow we will add a new special purpose
>>>> component for a niche industry, that will override the application
>>>> screens
>>>> with industry specific ones from that day on all OFBiz users that will
>>>> download and run OFBiz will have the impression that OFBiz was designed
>>>> for
>>>> one specific industry only.
>>>> Nicolas' proposal addresses this issue and still leaves the ability to
>>>> the
>>>> interested users to manually enable the components they need.
>>>>
>>>> Jacopo
>>>>
>>>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
>>>> [hidden email]
>>>>
>>>>> wrote:
>>>>> Hi Nicolas,
>>>>>
>>>>> I think If your finger hurts you don't cut it off. The project has too
>>>>> many
>>>>> pages, documentations, email threads and time dedicated to the special
>>>>> purpose components. They existed for a long, long time in the history of
>>>>> OFBiz.
>>>>>
>>>>> Some attempts were made in the past to reduce the size of the framework
>>>>> and
>>>>> release 13.07 is a prime example of these attempts which failed IMHO.
>>>>> This
>>>>> is a reason why, for example, a rewrite of the framework is being
>>>>> discussed
>>>>> in the community.
>>>>>
>>>>> I would suggest to you that to get really lean and clean, we need to
>>>>> work
>>>>> on the root of the problem which is the design of the framework and its
>>>>> architecture. We need a _plugin_ implementation that achieves _loose
>>>>> coupling_ of the components in a way that sustains the quality of the
>>>>> code
>>>>> while at the same time allowing a small framework core to thrive. Take a
>>>>> look at this thread <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>>> in
>>>>> which we discussed this issue and suggested one of several strategies.
>>>>> There are other threads which I cannot recall at the moment.
>>>>>
>>>>> For the record, I totally agree with keeping a small core and a lean
>>>>> framework, It's how we get there that I'm worried about and I would
>>>>> suggest
>>>>> to you that we do this in a well thought out and gradual process.
>>>>>
>>>>> My 2 cents
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>> Le 10/11/2015 05:54, [hidden email] a écrit :
>>>>>> This topic was heavily discussed in the past and I think a solution
>>>>>>> like
>>>>>>> turning off the components is very quick indeed but not ideal.
>>>>>>>
>>>>>>> Completely, I'm sure a better ideal exist but difficult to reach.
>>>>>> A second step, easy to reach would be enable a specialpurpose directly
>>>>>> by
>>>>>> an ant target :
>>>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>>>> or
>>>>>> $ ant load-component -D"components=ecommerce projectmgr myportal"
>>>>>> load-demo start
>>>>>>
>>>>>> This help beginner through easy command line to copy/past from
>>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>>

[Jacques Le Roux]

Sorry Nicolas, I'm not sure I totally get your points :)

Could you elaborate please?

Thanks

Jacques

Le 03/12/2015 23:33, Nicolas Malin a écrit :

> Jacques I understand.
>
> We can find a compromise if each specialpurpose components would be identify by meta-data like : demo, util, contrib, buisness specific to help the
> end user to load ofbiz with some component like he can load the data with load-seed or load-demo.
>
> But it's a second big step
>
> Le 24/11/2015 14:31, Jacques Le Roux a écrit :
>> Yes I see, as suggested by Nicolas. But it seems not obvious for a non technical person,  and they are often those who assess the product by simply
>> running the fasted and easiest ways (I do that also with other software, who don't? ;))
>> Like "Start" section at http://ofbiz.apache.org/download.html and others alike in wiki. Unfortunately you can only make 1 1st impression. Of
>> course, we possibly could give them an UI for that but we should at least change (all) our documentation.
>>
>> And even if we agree on this, the main part of the work remains: some components should not be "commented out".
>>
>> 1. AFAIK example and exampleext does not override anything and they are useful (at least to me), notably in official demo.
>> 2. Obviously, as it was in R13.07, ecommerce. But not sure the ecommerce component does not override applications...
>> 3. The POS is not concerned: not used in official demos, does not override anything.
>> 4. I wonder about the WepPos, does it overrides something, I don't think so but not sure
>> 5. Several persons spoke about the project manager, not sure it overrides applications.
>>
>> So the 1st step should be to clearly identify which components are concerned.
> ok :) can you give your preference for this 3 cases :
>  * source code
>  * official demo
>  * download release
>
> Nicolas
>>
>>
>> Jacopo said <<the default demo of OFBiz will only showcase the more specialized behaviors>> We could have all released demos not using some
>> specialpurpose components but trunk with all? It's bleeding edge after all.
>>
>> Jacques
>>
>> Le 21/11/2015 13:07, [hidden email] a écrit :
>>> Hi Jacques,
>>>
>>> what about a parameter using -D for the build script. we can also do something programmatic in the ./tools directory.
>>>
>>> Regards,
>>> --
>>>
>>> Taher Alkhateeb
>>>
>>>> On Nov 21, 2015, at 12:53 PM, Jacques Le Roux<[hidden email]>  wrote:
>>>>
>>>> I'd veto something which would blindly applies to all specialpurpose components, see my last post about that
>>>>
>>>> Jacques
>>>>
>>>> Le 21/11/2015 09:22, Jacopo Cappellato a écrit :
>>>>> Taher,
>>>>>
>>>>> I like your proposal; in fact this feature would be useful not only for
>>>>> automated deployments/tests but also to end users to easily enable the
>>>>> components they like.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> On Sat, Nov 21, 2015 at 8:53 AM,<[hidden email]>  wrote:
>>>>>>
>>>>>> Hi Jacopo,
>>>>>>
>>>>>> I would make a distinction between two things: a) preserve what exists and
>>>>>> b) prepare for the future.
>>>>>>
>>>>>> Doubtless what you are saying below makes perfect sense as a design
>>>>>> decision to allow for better future developments. I am concerned however
>>>>>> with what currently exists in specialpurpose. Specifically, I worry about
>>>>>> unit tests and Java Source code for framework integration. Changes we make
>>>>>> to the framework now needs to be followed up closely and we need to
>>>>>> manually enable, test and re-disable the specialpurpose components to
>>>>>> ensure continuous compatibility with trunk. Can we at least have a
>>>>>> modification in build.xml to enable / disable specialpurpose so that the
>>>>>> buildbot would continually test against specialpurpose?
>>>>>>
>>>>>> If you agree then I can try to write something to that effect in build.xml
>>>>>> at least to keep the code live in specialpurpose.
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>>> On Nov 19, 2015, at 4:36 PM, Jacopo Cappellato <
>>>>>>> [hidden email]> wrote:
>>>>>>> I was actually thinking to Birt as an example of this behavior: but in
>>>>>> the
>>>>>>> future we may add other special purpose applications that need to
>>>>>> override
>>>>>>> applications screens (in fact overriding screens and other artifacts to
>>>>>>> specialize them is a best practice in OFBiz) and the problem will happen
>>>>>>> again if we keep them all enabled.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>> Could we list, apart the well known Birt issue, special components which
>>>>>>>> are overriding main applications?
>>>>>>>>
>>>>>>>> Then depending on cases we could be more surgical...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> I agree with Taher when he says that we should strive to move small
>>>>>> steps
>>>>>>>>> in the direction of having a lean lightweight framework with pluggable
>>>>>>>>> components.
>>>>>>>>> But I think that Nicolas' proposal is actually one of these steps.
>>>>>>>>> The fact that currently some of our specialized components are
>>>>>> overriding
>>>>>>>>> the more generic behavior of other components (e.g. the ones under
>>>>>>>>> "applications") is a problem that we have to fix asap.
>>>>>>>>> Otherwise the default demo of OFBiz will only showcase the more
>>>>>>>>> specialized
>>>>>>>>> behaviors; for example, if tomorrow we will add a new special purpose
>>>>>>>>> component for a niche industry, that will override the application
>>>>>> screens
>>>>>>>>> with industry specific ones from that day on all OFBiz users that will
>>>>>>>>> download and run OFBiz will have the impression that OFBiz was designed
>>>>>>>>> for
>>>>>>>>> one specific industry only.
>>>>>>>>> Nicolas' proposal addresses this issue and still leaves the ability to
>>>>>> the
>>>>>>>>> interested users to manually enable the components they need.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
>>>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>> Hi Nicolas,
>>>>>>>>>>
>>>>>>>>>> I think If your finger hurts you don't cut it off. The project has too
>>>>>>>>>> many
>>>>>>>>>> pages, documentations, email threads and time dedicated to the special
>>>>>>>>>> purpose components. They existed for a long, long time in the history
>>>>>> of
>>>>>>>>>> OFBiz.
>>>>>>>>>>
>>>>>>>>>> Some attempts were made in the past to reduce the size of the
>>>>>> framework
>>>>>>>>>> and
>>>>>>>>>> release 13.07 is a prime example of these attempts which failed IMHO.
>>>>>>>>>> This
>>>>>>>>>> is a reason why, for example, a rewrite of the framework is being
>>>>>>>>>> discussed
>>>>>>>>>> in the community.
>>>>>>>>>>
>>>>>>>>>> I would suggest to you that to get really lean and clean, we need to
>>>>>> work
>>>>>>>>>> on the root of the problem which is the design of the framework and
>>>>>> its
>>>>>>>>>> architecture. We need a _plugin_ implementation that achieves _loose
>>>>>>>>>> coupling_ of the components in a way that sustains the quality of the
>>>>>>>>>> code
>>>>>>>>>> while at the same time allowing a small framework core to thrive.
>>>>>> Take a
>>>>>>>>>> look at this thread <
>>>>>> http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>>>>>>>> in
>>>>>>>>>> which we discussed this issue and suggested one of several strategies.
>>>>>>>>>> There are other threads which I cannot recall at the moment.
>>>>>>>>>>
>>>>>>>>>> For the record, I totally agree with keeping a small core and a lean
>>>>>>>>>> framework, It's how we get there that I'm worried about and I would
>>>>>>>>>> suggest
>>>>>>>>>> to you that we do this in a well thought out and gradual process.
>>>>>>>>>>
>>>>>>>>>> My 2 cents
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
>>>>>>>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Le 10/11/2015 05:54,[hidden email] a écrit :
>>>>>>>>>>> This topic was heavily discussed in the past and I think a solution
>>>>>> like
>>>>>>>>>>>> turning off the components is very quick indeed but not ideal.
>>>>>>>>>>>>
>>>>>>>>>>>> Completely, I'm sure a better ideal exist but difficult to reach.
>>>>>>>>>>> A second step, easy to reach would be enable a specialpurpose
>>>>>> directly
>>>>>>>>>>> by
>>>>>>>>>>> an ant target :
>>>>>>>>>>> $ ant load-component -D"component=ecommerce" load-demo start
>>>>>>>>>>> or
>>>>>>>>>>> $ ant load-component -D"components=ecommerce projectmgr myportal"
>>>>>>>>>>> load-demo start
>>>>>>>>>>>
>>>>>>>>>>> This help beginner through easy command line to copy/past from
>>>>>>>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>>>>>>>
>>>>>>>>>>> Nicolas
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
>>
>

[Nicolas Malin-2]

>>> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>>>
>>>> Could we list, apart the well known Birt issue, special components
>>>> which
>>>> are overriding main applications?
>>>>
>>> Directly by memory, the scrum components has defined new seca on cust
>>> request to send email that break the standard customer request system
>>>
>>> An other where I failed,  used service findProductsById instead of
>>> findProductById, the first from hhfacilty and the second from
>>> catalog. And
>>> want you start your hot-deploy component without specialpurpose ...
>>> paff !
>>> :)
>
> Thanks for these points Nicolas, I agree with Pierre suggestion.
>
> For instance does really the hhfacilty findProductById service needs
> to be named the same than in product? Etc.

Of course I'm also for this, but the problem isn't on the capacity to
open a jira issue.

Nicolas

[Jacques Le Roux]

Le 08/12/2015 20:59, Nicolas Malin a écrit :

>
>>>> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>>>>
>>>>> Could we list, apart the well known Birt issue, special components which
>>>>> are overriding main applications?
>>>>>
>>>> Directly by memory, the scrum components has defined new seca on cust
>>>> request to send email that break the standard customer request system
>>>>
>>>> An other where I failed,  used service findProductsById instead of
>>>> findProductById, the first from hhfacilty and the second from catalog. And
>>>> want you start your hot-deploy component without specialpurpose ... paff !
>>>> :)
>>
>> Thanks for these points Nicolas, I agree with Pierre suggestion.
>>
>> For instance does really the hhfacilty findProductById service needs to be named the same than in product? Etc.
> Of course I'm also for this, but the problem isn't on the capacity to open a jira issue.
>
> Nicolas
>

OK, I had an idea. Why not commenting out the specialpurpose components by default, but uncomment those which have proved to "not be a problem"?

"Not be a problem" means here which are not overriding applications component. So we could create a "Comment out specialpurpose components by default"
Jira
with possible subtasks for litigious cases (when we find an issue after uncommenting out)

I suggest though that we don't do that on trunk (which would still contains all components active) but on the next frozen release. We could even do it
on R14.12 if we have a consensus.

To start, I'd at least uncomment out:
example
exampleext
pos
ecommerce(? if not OK then we create the main Jira and a subtask for it)

Adds your please...

Opinions?

Jacques

[Ron Wheeler]

It seems that this discussion is just dancing around the core problem
with the current structure of OFBiz.

There seems to be a natural set of almost separate projects that are
lumped together into a rather tangled object.

This discussion is nibbling around the edge of the problem rather than
addressing the problem straight up.

To get to the next level of product maturity, we need to find a way to
break the product into manageable pieces with well defined rules about
how it gets extended and how "new" features get integrated.
The framework should be the first to get untangled since that is
supposed to be a separate product.
This is in progress but it not yet clear what the relationship will be
between the new framework and the old one or even OFBiz.

At some point, the leaders of this project are going to have to decide
what is the core ERP application. This means separating:
- core functionality
- core seed data
- seed Data for particular industries or
- demos
- optional application modules

Then there needs to be rules about how new things get added.

Breaking up the people who can commit to each area will add a bit of
discipline to the process.
At the moment any committer can change every level of the structure to
accomplish their goals.
This is very efficient for the person wanting to add something but
creates havoc for the project as a whole.

Getting to a point where releases of individual components can be made
without having to release everything at once will have a lot of benefits
and make it easier to maintain an OFBiz installation.
If you can upgrade the framework without updating the ERP, framework
improvements can be made more rapidly.
If the core ERP can be upgraded without having to worry about every
"special purpose" component ever created, it will get a lot easier to
get releases out.

This means that there will have to be rules and real APIs that you can
not violate.

It will also mean that people wanting to change things that require
changes to multiple levels will have to actually discuss their proposal
and convince the framework team or ERP team to add the required
functionality and test it to make sure that it does not break the API.

This will also increase the potential for community involvement.
Currently, it is too risky to add committers who only want to work on
one module or even a demo since there is no way to stop them breaking
lots of things accidentally.

Ron

On 14/12/2015 1:01 AM, Jacques Le Roux wrote:

> Le 08/12/2015 20:59, Nicolas Malin a écrit :
>>
>>>>> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>>>>>
>>>>>> Could we list, apart the well known Birt issue, special
>>>>>> components which
>>>>>> are overriding main applications?
>>>>>>
>>>>> Directly by memory, the scrum components has defined new seca on cust
>>>>> request to send email that break the standard customer request system
>>>>>
>>>>> An other where I failed,  used service findProductsById instead of
>>>>> findProductById, the first from hhfacilty and the second from
>>>>> catalog. And
>>>>> want you start your hot-deploy component without specialpurpose
>>>>> ... paff !
>>>>> :)
>>>
>>> Thanks for these points Nicolas, I agree with Pierre suggestion.
>>>
>>> For instance does really the hhfacilty findProductById service needs
>>> to be named the same than in product? Etc.
>> Of course I'm also for this, but the problem isn't on the capacity to
>> open a jira issue.
>>
>> Nicolas
>>
>
> OK, I had an idea. Why not commenting out the specialpurpose
> components by default, but uncomment those which have proved to "not
> be a problem"?
>
> "Not be a problem" means here which are not overriding applications
> component. So we could create a "Comment out specialpurpose components
> by default" Jira
> with possible subtasks for litigious cases (when we find an issue
> after uncommenting out)
>
> I suggest though that we don't do that on trunk (which would still
> contains all components active) but on the next frozen release. We
> could even do it on R14.12 if we have a consensus.
>
> To start, I'd at least uncomment out:
> example
> exampleext
> pos
> ecommerce(? if not OK then we create the main Jira and a subtask for it)
>
> Adds your please...
>
> Opinions?
>
> Jacques
>

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

[Jacques Le Roux]

Hi Ron,

It's interesting, and I agree with you we must organise the project and ourselves "more". But it's too early for me at the moment :/
Sorry but I prefer to keep focused on simple tasks (baby steps) for now, this one is about specialpurpose components :)

Note that another baby step we have already decided on is to group the applications data model in one component.
This should hopefully clarify things at the applications level. I think most dependencies are due to the data model, but I'm not quite sure about that.

Jacques
PS: BTW I just found this article interesting http://breakingsmart.com/season-1/rough-consensus-and-maximal-interestingness . Seems that there are a
bunch of others as interesting there.


Le 14/12/2015 16:47, Ron Wheeler a écrit :

> It seems that this discussion is just dancing around the core problem with the current structure of OFBiz.
>
> There seems to be a natural set of almost separate projects that are lumped together into a rather tangled object.
>
> This discussion is nibbling around the edge of the problem rather than addressing the problem straight up.
>
> To get to the next level of product maturity, we need to find a way to break the product into manageable pieces with well defined rules about how it
> gets extended and how "new" features get integrated.
> The framework should be the first to get untangled since that is supposed to be a separate product.
> This is in progress but it not yet clear what the relationship will be between the new framework and the old one or even OFBiz.
>
> At some point, the leaders of this project are going to have to decide what is the core ERP application. This means separating:
> - core functionality
> - core seed data
> - seed Data for particular industries or
> - demos
> - optional application modules
>
> Then there needs to be rules about how new things get added.
>
> Breaking up the people who can commit to each area will add a bit of discipline to the process.
> At the moment any committer can change every level of the structure to accomplish their goals.
> This is very efficient for the person wanting to add something but creates havoc for the project as a whole.
>
> Getting to a point where releases of individual components can be made without having to release everything at once will have a lot of benefits and
> make it easier to maintain an OFBiz installation.
> If you can upgrade the framework without updating the ERP, framework improvements can be made more rapidly.
> If the core ERP can be upgraded without having to worry about every "special purpose" component ever created, it will get a lot easier to get
> releases out.
>
> This means that there will have to be rules and real APIs that you can not violate.
>
> It will also mean that people wanting to change things that require changes to multiple levels will have to actually discuss their proposal and
> convince the framework team or ERP team to add the required functionality and test it to make sure that it does not break the API.
>
> This will also increase the potential for community involvement. Currently, it is too risky to add committers who only want to work on one module or
> even a demo since there is no way to stop them breaking lots of things accidentally.
>
> Ron
>
> On 14/12/2015 1:01 AM, Jacques Le Roux wrote:
>> Le 08/12/2015 20:59, Nicolas Malin a écrit :
>>>
>>>>>> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>>>>>>
>>>>>>> Could we list, apart the well known Birt issue, special components which
>>>>>>> are overriding main applications?
>>>>>>>
>>>>>> Directly by memory, the scrum components has defined new seca on cust
>>>>>> request to send email that break the standard customer request system
>>>>>>
>>>>>> An other where I failed,  used service findProductsById instead of
>>>>>> findProductById, the first from hhfacilty and the second from catalog. And
>>>>>> want you start your hot-deploy component without specialpurpose ... paff !
>>>>>> :)
>>>>
>>>> Thanks for these points Nicolas, I agree with Pierre suggestion.
>>>>
>>>> For instance does really the hhfacilty findProductById service needs to be named the same than in product? Etc.
>>> Of course I'm also for this, but the problem isn't on the capacity to open a jira issue.
>>>
>>> Nicolas
>>>
>>
>> OK, I had an idea. Why not commenting out the specialpurpose components by default, but uncomment those which have proved to "not be a problem"?
>>
>> "Not be a problem" means here which are not overriding applications component. So we could create a "Comment out specialpurpose components by
>> default" Jira
>> with possible subtasks for litigious cases (when we find an issue after uncommenting out)
>>
>> I suggest though that we don't do that on trunk (which would still contains all components active) but on the next frozen release. We could even do
>> it on R14.12 if we have a consensus.
>>
>> To start, I'd at least uncomment out:
>> example
>> exampleext
>> pos
>> ecommerce(? if not OK then we create the main Jira and a subtask for it)
>>
>> Adds your please...
>>
>> Opinions?
>>
>> Jacques
>>
>
>

[Ron Wheeler]

On 14/12/2015 4:40 PM, Jacques Le Roux wrote:
> Hi Ron,
>
> It's interesting, and I agree with you we must organise the project
> and ourselves "more". But it's too early for me at the moment :/
> Sorry but I prefer to keep focused on simple tasks (baby steps) for
> now, this one is about specialpurpose components :)
It is a start and is raising the discussion about structure even if it
is not as sweeping as I would like.
The discussion itself is valuable in bringing some hidden agendas and
undocumented usage and dreams to the fore.

>
> Note that another baby step we have already decided on is to group the
> applications data model in one component.
> This should hopefully clarify things at the applications level. I
> think most dependencies are due to the data model, but I'm not quite
> sure about that.
Anything that decouples the various parts is a good step and even if
some problems are found that can not be solved immediately at least they
will have been identified.

>
> Jacques
> PS: BTW I just found this article interesting
> http://breakingsmart.com/season-1/rough-consensus-and-maximal-interestingness 
> . Seems that there are a bunch of others as interesting there.
>

It would be much easier to follow some of the idea expressed here about
agility, freedom and rough consensus if the risks were minimized by
limiting the scope of the impact of the decisions.

Ron

>
> Le 14/12/2015 16:47, Ron Wheeler a écrit :
>> It seems that this discussion is just dancing around the core problem
>> with the current structure of OFBiz.
>>
>> There seems to be a natural set of almost separate projects that are
>> lumped together into a rather tangled object.
>>
>> This discussion is nibbling around the edge of the problem rather
>> than addressing the problem straight up.
>>
>> To get to the next level of product maturity, we need to find a way
>> to break the product into manageable pieces with well defined rules
>> about how it gets extended and how "new" features get integrated.
>> The framework should be the first to get untangled since that is
>> supposed to be a separate product.
>> This is in progress but it not yet clear what the relationship will
>> be between the new framework and the old one or even OFBiz.
>>
>> At some point, the leaders of this project are going to have to
>> decide what is the core ERP application. This means separating:
>> - core functionality
>> - core seed data
>> - seed Data for particular industries or
>> - demos
>> - optional application modules
>>
>> Then there needs to be rules about how new things get added.
>>
>> Breaking up the people who can commit to each area will add a bit of
>> discipline to the process.
>> At the moment any committer can change every level of the structure
>> to accomplish their goals.
>> This is very efficient for the person wanting to add something but
>> creates havoc for the project as a whole.
>>
>> Getting to a point where releases of individual components can be
>> made without having to release everything at once will have a lot of
>> benefits and make it easier to maintain an OFBiz installation.
>> If you can upgrade the framework without updating the ERP, framework
>> improvements can be made more rapidly.
>> If the core ERP can be upgraded without having to worry about every
>> "special purpose" component ever created, it will get a lot easier to
>> get releases out.
>>
>> This means that there will have to be rules and real APIs that you
>> can not violate.
>>
>> It will also mean that people wanting to change things that require
>> changes to multiple levels will have to actually discuss their
>> proposal and convince the framework team or ERP team to add the
>> required functionality and test it to make sure that it does not
>> break the API.
>>
>> This will also increase the potential for community involvement.
>> Currently, it is too risky to add committers who only want to work on
>> one module or even a demo since there is no way to stop them breaking
>> lots of things accidentally.
>>
>> Ron
>>
>> On 14/12/2015 1:01 AM, Jacques Le Roux wrote:
>>> Le 08/12/2015 20:59, Nicolas Malin a écrit :
>>>>
>>>>>>> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>>>>>>>
>>>>>>>> Could we list, apart the well known Birt issue, special
>>>>>>>> components which
>>>>>>>> are overriding main applications?
>>>>>>>>
>>>>>>> Directly by memory, the scrum components has defined new seca on
>>>>>>> cust
>>>>>>> request to send email that break the standard customer request
>>>>>>> system
>>>>>>>
>>>>>>> An other where I failed,  used service findProductsById instead of
>>>>>>> findProductById, the first from hhfacilty and the second from
>>>>>>> catalog. And
>>>>>>> want you start your hot-deploy component without specialpurpose
>>>>>>> ... paff !
>>>>>>> :)
>>>>>
>>>>> Thanks for these points Nicolas, I agree with Pierre suggestion.
>>>>>
>>>>> For instance does really the hhfacilty findProductById service
>>>>> needs to be named the same than in product? Etc.
>>>> Of course I'm also for this, but the problem isn't on the capacity
>>>> to open a jira issue.
>>>>
>>>> Nicolas
>>>>
>>>
>>> OK, I had an idea. Why not commenting out the specialpurpose
>>> components by default, but uncomment those which have proved to "not
>>> be a problem"?
>>>
>>> "Not be a problem" means here which are not overriding applications
>>> component. So we could create a "Comment out specialpurpose
>>> components by default" Jira
>>> with possible subtasks for litigious cases (when we find an issue
>>> after uncommenting out)
>>>
>>> I suggest though that we don't do that on trunk (which would still
>>> contains all components active) but on the next frozen release. We
>>> could even do it on R14.12 if we have a consensus.
>>>
>>> To start, I'd at least uncomment out:
>>> example
>>> exampleext
>>> pos
>>> ecommerce(? if not OK then we create the main Jira and a subtask for
>>> it)
>>>
>>> Adds your please...
>>>
>>> Opinions?
>>>
>>> Jacques
>>>
>>
>>
>

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