[Proposition] deactivate by default all specialpurpose component

[Nicolas Malin <ni...@nereide.fr>]

Hello,

With some latest great discussion about keep or not keep specialpurpose 
components on branch, I some inconvenience come from that a 
specialpurpose can be overload the definition (service, entity or 
something like that) present on application component.

It's easier, we can comment all lines present on 
specialpurpose/component-load.xml and if some people want use a specific 
component, just uncomment it :)

I see two advantages :
  * detect bad depends easily (a application or framework that use 
specialpurpose)
  * detect if a component it on the good place

Your comments ?

Nicolas

Re: [Proposition] deactivate by default all specialpurpose component

[Pierre Smits <pi...@gmail.com>]

Niche specific demos of OFBiz can be facilitated with more niche specific
demo data. Associating documentation will help in building the desired
expectations.

For now I don't believe this project will ever be able to showcase every
niche specific demo. But it will be able to showcase a few generics. And it
should, as it will drive adoption. Leave it up to the contributors working
for implementation/integration parties to assist in niche demos.

Best regards,



Pierre Smits

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

On Thu, Nov 19, 2015 at 9:46 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> 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 <
> slidingfilaments@gmail.com
> > 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 <
> nicolas.malin@nereide.fr>
> > wrote:
> >
> > > Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
> > >
> > >
> >
>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

My opinion is we should do so for concerned component but not all others blindly. For instance the POS it out of scope and so are many others.
So we should better name those which are concerned, current or future...

Jacques

Le 19/11/2015 14:36, Jacopo Cappellato a écrit :
> 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 <
> jacques.le.roux@les7arts.com> 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 <
>>> slidingfilaments@gmail.com
>>>
>>>> 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 <
>>>> nicolas.malin@nereide.fr>
>>>> wrote:
>>>>
>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>>
>>>>>
>>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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, slidingfilaments@gmail.com 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<ja...@les7arts.com>  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,<sl...@gmail.com>  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 <
>>>>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>>>>> slidingfilaments@gmail.com
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> nicolas.malin@nereide.fr>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Le 10/11/2015 05:54,slidingfilaments@gmail.com 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
>>
>

Re: [Proposition] deactivate by default all specialpurpose component

[Nicolas Malin <ni...@nereide.fr>]

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, slidingfilaments@gmail.com 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<ja...@les7arts.com>  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,<sl...@gmail.com>  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 <
>>>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>>>> slidingfilaments@gmail.com
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> nicolas.malin@nereide.fr>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Le 10/11/2015 05:54,slidingfilaments@gmail.com  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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
>

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler <rw...@artifact-software.com>]

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, slidingfilaments@gmail.com 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<ja...@les7arts.com> 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,<sl...@gmail.com>  
>>>>>>> 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 <
>>>>>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>>>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>>>>>> slidingfilaments@gmail.com
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> nicolas.malin@nereide.fr>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Le 10/11/2015 05:54,slidingfilaments@gmail.com 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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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, slidingfilaments@gmail.com 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<ja...@les7arts.com>  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,<sl...@gmail.com>  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 <
>>>>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>>>>> slidingfilaments@gmail.com
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> nicolas.malin@nereide.fr>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Le 10/11/2015 05:54,slidingfilaments@gmail.com 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
>>
>
>

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler <rw...@artifact-software.com>]

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, slidingfilaments@gmail.com 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<ja...@les7arts.com>  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,<sl...@gmail.com>  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 <
>>>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>>>> slidingfilaments@gmail.com
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> nicolas.malin@nereide.fr>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Le 10/11/2015 05:54,slidingfilaments@gmail.com  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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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, slidingfilaments@gmail.com 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<ja...@les7arts.com>  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,<sl...@gmail.com>  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 <
>>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>>> slidingfilaments@gmail.com
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> nicolas.malin@nereide.fr>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Le 10/11/2015 05:54,slidingfilaments@gmail.com  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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[sl...@gmail.com]

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 <ja...@les7arts.com> 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, <sl...@gmail.com> 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 <
>>>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>>> jacques.le.roux@les7arts.com> 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 <
>>>>>> slidingfilaments@gmail.com
>>>>>> 
>>>>>>> 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 <
>>>>>>> nicolas.malin@nereide.fr>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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, <sl...@gmail.com> 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 <
>> jacopo.cappellato@hotwaxsystems.com> 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 <
>>> jacques.le.roux@les7arts.com> 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 <
>>>>> slidingfilaments@gmail.com
>>>>>
>>>>>> 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 <
>>>>>> nicolas.malin@nereide.fr>
>>>>>> wrote:
>>>>>>
>>>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>>>>
>>>>>>>
>>>>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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, <sl...@gmail.com> 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 <
> jacopo.cappellato@hotwaxsystems.com> 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 <
> > jacques.le.roux@les7arts.com> 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 <
> >>> slidingfilaments@gmail.com
> >>>
> >>>> 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 <
> >>>> nicolas.malin@nereide.fr>
> >>>> wrote:
> >>>>
> >>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
> >>>>>
> >>>>>
> >>>>>
>

Re: [Proposition] deactivate by default all specialpurpose component

[sl...@gmail.com]

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 <ja...@hotwaxsystems.com> 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 <
> jacques.le.roux@les7arts.com> 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 <
>>> slidingfilaments@gmail.com
>>> 
>>>> 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 <
>>>> nicolas.malin@nereide.fr>
>>>> wrote:
>>>> 
>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>> 
>>>>> 
>>>>> 

Re: [Proposition] deactivate by default all specialpurpose component

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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 <
jacques.le.roux@les7arts.com> 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 <
>> slidingfilaments@gmail.com
>>
>>> 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 <
>>> nicolas.malin@nereide.fr>
>>> wrote:
>>>
>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>
>>>>
>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler <rw...@artifact-software.com>]

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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler <rw...@artifact-software.com>]

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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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

Re: [Proposition] deactivate by default all specialpurpose component

[Nicolas Malin <ni...@nereide.fr>]

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

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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 <ni...@nereide.fr>
> 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 <
>>>> slidingfilaments@gmail.com
>>>>
>>>>> 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 <
>>>>> nicolas.malin@nereide.fr>
>>>>> wrote:
>>>>>
>>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>>>
>>>>>>
>>>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Pierre Smits <pi...@gmail.com>]

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 <ni...@nereide.fr>
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 <
>>> slidingfilaments@gmail.com
>>>
>>>> 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 <
>>>> nicolas.malin@nereide.fr>
>>>> wrote:
>>>>
>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>>
>>>>>
>>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Nicolas Malin <ni...@nereide.fr>]

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 
>> <slidingfilaments@gmail.com
>>> 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 
>>> <ni...@nereide.fr>
>>> wrote:
>>>
>>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>>
>>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

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 <slidingfilaments@gmail.com
>> 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 <ni...@nereide.fr>
>> wrote:
>>
>>> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>>>
>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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 <slidingfilaments@gmail.com
> 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 <ni...@nereide.fr>
> wrote:
>
> > Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
> >
> >
>

Re: [Proposition] deactivate by default all specialpurpose component

[Taher Alkhateeb <sl...@gmail.com>]

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 <ni...@nereide.fr>
wrote:

> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>
>

Re: [Proposition] deactivate by default all specialpurpose component

[Pierre Smits <pi...@gmail.com>]

Do you mean that we are going create ant tasks for every special purpose?

Best regards,

Pierre Smits

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

On Wed, Nov 18, 2015 at 9:22 PM, Nicolas Malin <ni...@nereide.fr>
wrote:

> Le 10/11/2015 05:54, slidingfilaments@gmail.com 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
>
>

Re: [Proposition] deactivate by default all specialpurpose component

[Nicolas Malin <ni...@nereide.fr>]

Le 10/11/2015 05:54, slidingfilaments@gmail.com 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

Re: [Proposition] deactivate by default all specialpurpose component

[Pierre Smits <pi...@gmail.com>]

The r13.07 branch and its releases are painful to everybody (and more
importantly our new adopters) as they don't find in the releases what is
advertised elsewhere in projects web and wiki pages. This has been shown in
various threads in the user ml. And this keeps going on as long as we keep
r13.07 as the basis of 'latest stable release'.

Best regards,

Pierre Smits

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

On Tue, Nov 10, 2015 at 5:54 AM, <sl...@gmail.com> wrote:

> Hi Nicolas,
>
> The 13.07 to me was a painful release to deal with because of stripping
> out the specialpurpose components. Also disabling these components means
> lower quality, no testing and no guarantee of being compatible with the
> current version of trunk. So i would imagine this to be sort of equivalent
> to killing these components some of which i find very useful like BIRT,
> project management and ecommerce.
>
> 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.
>
> Taher Alkhateeb
>
> > On Nov 10, 2015, at 12:40 AM, Nicolas Malin <ni...@nereide.fr>
> wrote:
> >
> > Hello,
> >
> > With some latest great discussion about keep or not keep specialpurpose
> components on branch, I some inconvenience come from that a specialpurpose
> can be overload the definition (service, entity or something like that)
> present on application component.
> >
> > It's easier, we can comment all lines present on
> specialpurpose/component-load.xml and if some people want use a specific
> component, just uncomment it :)
> >
> > I see two advantages :
> > * detect bad depends easily (a application or framework that use
> specialpurpose)
> > * detect if a component it on the good place
> >
> > Your comments ?
> >
> > Nicolas
>

Re: [Proposition] deactivate by default all specialpurpose component

[sl...@gmail.com]

Hi Nicolas,

The 13.07 to me was a painful release to deal with because of stripping out the specialpurpose components. Also disabling these components means lower quality, no testing and no guarantee of being compatible with the current version of trunk. So i would imagine this to be sort of equivalent to killing these components some of which i find very useful like BIRT, project management and ecommerce.

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.

Taher Alkhateeb

> On Nov 10, 2015, at 12:40 AM, Nicolas Malin <ni...@nereide.fr> wrote:
> 
> Hello,
> 
> With some latest great discussion about keep or not keep specialpurpose components on branch, I some inconvenience come from that a specialpurpose can be overload the definition (service, entity or something like that) present on application component.
> 
> It's easier, we can comment all lines present on specialpurpose/component-load.xml and if some people want use a specific component, just uncomment it :)
> 
> I see two advantages :
> * detect bad depends easily (a application or framework that use specialpurpose)
> * detect if a component it on the good place
> 
> Your comments ?
> 
> Nicolas

Re: [Proposition] deactivate by default all specialpurpose component

[Nicolas Malin <ni...@nereide.fr>]

Le 10/11/2015 23:26, Jacques Le Roux a écrit :
> I made another proposition earlier but not too long ago 
> http://markmail.org/message/ypmrbqkb7y2gh4f5
>
> But it seems nobody was interested :/ (OK, the thread referenced in 
> the reference above is really long to read :D, but the message is not)
>
> I wonder why. It seems ideal to me: we don't release code we don't 
> want in releases, but we can still propose it to our users in a 
> reliable way and it's maintained.
> With Nicolas's proposition I fear the maintenance part could be 
> overlooked as Taher mentionned.
Yes I agree also with Taher, but what's the better way with own resources :
  * Have a strong quality on application
  * Have a working application with specialpurpose rules.

With my feed back, all site project works with application, I use 
sometime a specialpurpose component but rarely.
So the fear is also on true on the other ways.

So now I deactivate all specialpurpose before starting a new project to 
ensure that I have only standard process.
>
> On the other hand I'd not be against moving more components to Attic 
> if they deserve it...
> Contrary to POS or projectmgr, I don't remember users asking for 
> google and ebay components missing in R13...
> Also what about Oagis, who really care (there are some entries in wiki 
> but old and not maintained)?
>
> I don't remember if I made this proposition already: rather than 
> moving those components to Attic (ie remove but still have at a 
> revision in repo) we could keep them in an attic sub-folder under 
> specialpurpose before really removing them.
> And generally we could use sub-folders to better organise things. Like 
> putting google and ebay components under ecomComplements rather than 
> in an attic folder, projectmgr and scrumm could be alsogrouped ,solr 
> and lucene too, example and exampleext, ldap and passport, etc.
sure, but i thinks this it out from my little proposal ;)

Nicolas
>
> Jacques
>
> Le 10/11/2015 09:48, Jacopo Cappellato a écrit :
>> Hi Nicolas,
>>
>> I like your proposal.
>>
>> Jacopo
>>
>> On Mon, Nov 9, 2015 at 10:40 PM, Nicolas Malin 
>> <ni...@nereide.fr>
>> wrote:
>>
>>> Hello,
>>>
>>> With some latest great discussion about keep or not keep specialpurpose
>>> components on branch, I some inconvenience come from that a 
>>> specialpurpose
>>> can be overload the definition (service, entity or something like that)
>>> present on application component.
>>>
>>> It's easier, we can comment all lines present on
>>> specialpurpose/component-load.xml and if some people want use a 
>>> specific
>>> component, just uncomment it :)
>>>
>>> I see two advantages :
>>>   * detect bad depends easily (a application or framework that use
>>> specialpurpose)
>>>   * detect if a component it on the good place
>>>
>>> Your comments ?
>>>
>>> Nicolas
>>>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacques Le Roux <ja...@les7arts.com>]

I made another proposition earlier but not too long ago http://markmail.org/message/ypmrbqkb7y2gh4f5

But it seems nobody was interested :/ (OK, the thread referenced in the reference above is really long to read :D, but the message is not)

I wonder why. It seems ideal to me: we don't release code we don't want in releases, but we can still propose it to our users in a reliable way and 
it's maintained.
With Nicolas's proposition I fear the maintenance part could be overlooked as Taher mentionned.

On the other hand I'd not be against moving more components to Attic if they deserve it...
Contrary to POS or projectmgr, I don't remember users asking for google and ebay components missing in R13...
Also what about Oagis, who really care (there are some entries in wiki but old and not maintained)?

I don't remember if I made this proposition already: rather than moving those components to Attic (ie remove but still have at a revision in repo) we 
could keep them in an attic sub-folder under specialpurpose before really removing them.
And generally we could use sub-folders to better organise things. Like putting google and ebay components under ecomComplements rather than in an 
attic folder, projectmgr and scrumm could be alsogrouped ,solr and lucene too, example and exampleext, ldap and passport, etc.

Jacques

Le 10/11/2015 09:48, Jacopo Cappellato a écrit :
> Hi Nicolas,
>
> I like your proposal.
>
> Jacopo
>
> On Mon, Nov 9, 2015 at 10:40 PM, Nicolas Malin <ni...@nereide.fr>
> wrote:
>
>> Hello,
>>
>> With some latest great discussion about keep or not keep specialpurpose
>> components on branch, I some inconvenience come from that a specialpurpose
>> can be overload the definition (service, entity or something like that)
>> present on application component.
>>
>> It's easier, we can comment all lines present on
>> specialpurpose/component-load.xml and if some people want use a specific
>> component, just uncomment it :)
>>
>> I see two advantages :
>>   * detect bad depends easily (a application or framework that use
>> specialpurpose)
>>   * detect if a component it on the good place
>>
>> Your comments ?
>>
>> Nicolas
>>

Re: [Proposition] deactivate by default all specialpurpose component

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

Hi Nicolas,

I like your proposal.

Jacopo

On Mon, Nov 9, 2015 at 10:40 PM, Nicolas Malin <ni...@nereide.fr>
wrote:

> Hello,
>
> With some latest great discussion about keep or not keep specialpurpose
> components on branch, I some inconvenience come from that a specialpurpose
> can be overload the definition (service, entity or something like that)
> present on application component.
>
> It's easier, we can comment all lines present on
> specialpurpose/component-load.xml and if some people want use a specific
> component, just uncomment it :)
>
> I see two advantages :
>  * detect bad depends easily (a application or framework that use
> specialpurpose)
>  * detect if a component it on the good place
>
> Your comments ?
>
> Nicolas
>