[Proposition] deactivate by default all specialpurpose component

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Proposition] deactivate by default all specialpurpose component

Nicolas Malin-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

taher
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Pierre Smits
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, <[hidden email]> 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 <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Jacopo Cappellato-5
In reply to this post by Nicolas Malin-2
Hi Nicolas,

I like your proposal.

Jacopo

On Mon, Nov 9, 2015 at 10:40 PM, Nicolas Malin <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Jacques Le Roux
Administrator
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 <[hidden email]>
> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Nicolas Malin-2
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
>> <[hidden email]>
>> 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
>>>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Nicolas Malin-2
In reply to this post by taher
Le 10/11/2015 05:54, [hidden email] a écrit :
> This topic was heavily discussed in the past and I think a solution like turning off the components is very quick indeed but not ideal.

Completely, I'm sure a better ideal exist but difficult to reach.

A second step, easy to reach would be enable a specialpurpose directly by an ant target :
$ ant load-component -D"component=ecommerce" load-demo start
or
$ ant load-component -D"components=ecommerce projectmgr myportal" load-demo start

This help beginner through easy command line to copy/past from documentation or expert by scripting to configure ofbiz.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Pierre Smits
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 <[hidden email]>
wrote:

> Le 10/11/2015 05:54, [hidden email] a écrit :
>
>> This topic was heavily discussed in the past and I think a solution like
>> turning off the components is very quick indeed but not ideal.
>>
>
> Completely, I'm sure a better ideal exist but difficult to reach.
>
> A second step, easy to reach would be enable a specialpurpose directly by
> an ant target :
> $ ant load-component -D"component=ecommerce" load-demo start
> or
> $ ant load-component -D"components=ecommerce projectmgr myportal"
> load-demo start
>
> This help beginner through easy command line to copy/past from
> documentation or expert by scripting to configure ofbiz.
>
> Nicolas
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

taher
In reply to this post by Nicolas Malin-2
Hi Nicolas,

I think If your finger hurts you don't cut it off. The project has too many
pages, documentations, email threads and time dedicated to the special
purpose components. They existed for a long, long time in the history of
OFBiz.

Some attempts were made in the past to reduce the size of the framework and
release 13.07 is a prime example of these attempts which failed IMHO. This
is a reason why, for example, a rewrite of the framework is being discussed
in the community.

I would suggest to you that to get really lean and clean, we need to work
on the root of the problem which is the design of the framework and its
architecture. We need a _plugin_ implementation that achieves _loose
coupling_ of the components in a way that sustains the quality of the code
while at the same time allowing a small framework core to thrive. Take a
look at this thread <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff> in
which we discussed this issue and suggested one of several strategies.
There are other threads which I cannot recall at the moment.

For the record, I totally agree with keeping a small core and a lean
framework, It's how we get there that I'm worried about and I would suggest
to you that we do this in a well thought out and gradual process.

My 2 cents

Taher Alkhateeb

On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <[hidden email]>
wrote:

> Le 10/11/2015 05:54, [hidden email] a écrit :
>
>> This topic was heavily discussed in the past and I think a solution like
>> turning off the components is very quick indeed but not ideal.
>>
>
> Completely, I'm sure a better ideal exist but difficult to reach.
>
> A second step, easy to reach would be enable a specialpurpose directly by
> an ant target :
> $ ant load-component -D"component=ecommerce" load-demo start
> or
> $ ant load-component -D"components=ecommerce projectmgr myportal"
> load-demo start
>
> This help beginner through easy command line to copy/past from
> documentation or expert by scripting to configure ofbiz.
>
> Nicolas
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Jacopo Cappellato-5
I agree with Taher when he says that we should strive to move small steps
in the direction of having a lean lightweight framework with pluggable
components.
But I think that Nicolas' proposal is actually one of these steps.
The fact that currently some of our specialized components are overriding
the more generic behavior of other components (e.g. the ones under
"applications") is a problem that we have to fix asap.
Otherwise the default demo of OFBiz will only showcase the more specialized
behaviors; for example, if tomorrow we will add a new special purpose
component for a niche industry, that will override the application screens
with industry specific ones from that day on all OFBiz users that will
download and run OFBiz will have the impression that OFBiz was designed for
one specific industry only.
Nicolas' proposal addresses this issue and still leaves the ability to the
interested users to manually enable the components they need.

Jacopo

On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Nicolas,
>
> I think If your finger hurts you don't cut it off. The project has too many
> pages, documentations, email threads and time dedicated to the special
> purpose components. They existed for a long, long time in the history of
> OFBiz.
>
> Some attempts were made in the past to reduce the size of the framework and
> release 13.07 is a prime example of these attempts which failed IMHO. This
> is a reason why, for example, a rewrite of the framework is being discussed
> in the community.
>
> I would suggest to you that to get really lean and clean, we need to work
> on the root of the problem which is the design of the framework and its
> architecture. We need a _plugin_ implementation that achieves _loose
> coupling_ of the components in a way that sustains the quality of the code
> while at the same time allowing a small framework core to thrive. Take a
> look at this thread <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff> in
> which we discussed this issue and suggested one of several strategies.
> There are other threads which I cannot recall at the moment.
>
> For the record, I totally agree with keeping a small core and a lean
> framework, It's how we get there that I'm worried about and I would suggest
> to you that we do this in a well thought out and gradual process.
>
> My 2 cents
>
> Taher Alkhateeb
>
> On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <[hidden email]>
> wrote:
>
> > Le 10/11/2015 05:54, [hidden email] a écrit :
> >
> >> This topic was heavily discussed in the past and I think a solution like
> >> turning off the components is very quick indeed but not ideal.
> >>
> >
> > Completely, I'm sure a better ideal exist but difficult to reach.
> >
> > A second step, easy to reach would be enable a specialpurpose directly by
> > an ant target :
> > $ ant load-component -D"component=ecommerce" load-demo start
> > or
> > $ ant load-component -D"components=ecommerce projectmgr myportal"
> > load-demo start
> >
> > This help beginner through easy command line to copy/past from
> > documentation or expert by scripting to configure ofbiz.
> >
> > Nicolas
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Pierre Smits
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 <
[hidden email]> 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 <
> [hidden email]
> > wrote:
>
> > Hi Nicolas,
> >
> > I think If your finger hurts you don't cut it off. The project has too
> many
> > pages, documentations, email threads and time dedicated to the special
> > purpose components. They existed for a long, long time in the history of
> > OFBiz.
> >
> > Some attempts were made in the past to reduce the size of the framework
> and
> > release 13.07 is a prime example of these attempts which failed IMHO.
> This
> > is a reason why, for example, a rewrite of the framework is being
> discussed
> > in the community.
> >
> > I would suggest to you that to get really lean and clean, we need to work
> > on the root of the problem which is the design of the framework and its
> > architecture. We need a _plugin_ implementation that achieves _loose
> > coupling_ of the components in a way that sustains the quality of the
> code
> > while at the same time allowing a small framework core to thrive. Take a
> > look at this thread <http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
> in
> > which we discussed this issue and suggested one of several strategies.
> > There are other threads which I cannot recall at the moment.
> >
> > For the record, I totally agree with keeping a small core and a lean
> > framework, It's how we get there that I'm worried about and I would
> suggest
> > to you that we do this in a well thought out and gradual process.
> >
> > My 2 cents
> >
> > Taher Alkhateeb
> >
> > On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
> [hidden email]>
> > wrote:
> >
> > > Le 10/11/2015 05:54, [hidden email] a écrit :
> > >
> > >> This topic was heavily discussed in the past and I think a solution
> like
> > >> turning off the components is very quick indeed but not ideal.
> > >>
> > >
> > > Completely, I'm sure a better ideal exist but difficult to reach.
> > >
> > > A second step, easy to reach would be enable a specialpurpose directly
> by
> > > an ant target :
> > > $ ant load-component -D"component=ecommerce" load-demo start
> > > or
> > > $ ant load-component -D"components=ecommerce projectmgr myportal"
> > > load-demo start
> > >
> > > This help beginner through easy command line to copy/past from
> > > documentation or expert by scripting to configure ofbiz.
> > >
> > > Nicolas
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Jacques Le Roux
Administrator
In reply to this post by Jacopo Cappellato-5
Could we list, apart the well known Birt issue, special components which are overriding main applications?

Then depending on cases we could be more surgical...

Jacques

Le 19/11/2015 09:46, Jacopo Cappellato a écrit :

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

Re: [Proposition] deactivate by default all specialpurpose component

Jacopo Cappellato-5
I was actually thinking to Birt as an example of this behavior: but in the
future we may add other special purpose applications that need to override
applications screens (in fact overriding screens and other artifacts to
specialize them is a best practice in OFBiz) and the problem will happen
again if we keep them all enabled.

Jacopo

On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
[hidden email]> wrote:

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

taher
In reply to this post by Jacopo Cappellato-5
Hi Jacopo,

I would make a distinction between two things: a) preserve what exists and b) prepare for the future.

Doubtless what you are saying below makes perfect sense as a design decision to allow for better future developments. I am concerned however with what currently exists in specialpurpose. Specifically, I worry about unit tests and Java Source code for framework integration. Changes we make to the framework now needs to be followed up closely and we need to manually enable, test and re-disable the specialpurpose components to ensure continuous compatibility with trunk. Can we at least have a modification in build.xml to enable / disable specialpurpose so that the buildbot would continually test against specialpurpose?

If you agree then I can try to write something to that effect in build.xml at least to keep the code live in specialpurpose.

Regards,
--

Taher Alkhateeb

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

Re: [Proposition] deactivate by default all specialpurpose component

Jacopo Cappellato-5
Taher,

I like your proposal; in fact this feature would be useful not only for
automated deployments/tests but also to end users to easily enable the
components they like.

Jacopo

On Sat, Nov 21, 2015 at 8:53 AM, <[hidden email]> wrote:

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

Re: [Proposition] deactivate by default all specialpurpose component

Jacques Le Roux
Administrator
I'd veto something which would blindly applies to all specialpurpose components, see my last post about that

Jacques

Le 21/11/2015 09:22, Jacopo Cappellato a écrit :

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

Re: [Proposition] deactivate by default all specialpurpose component

taher
Hi Jacques,

what about a parameter using -D for the build script. we can also do something programmatic in the ./tools directory.

Regards,
--

Taher Alkhateeb

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

Re: [Proposition] deactivate by default all specialpurpose component

Jacques Le Roux
Administrator
Yes I see, as suggested by Nicolas. But it seems not obvious for a non technical person,  and they are often those who assess the product by simply
running the fasted and easiest ways (I do that also with other software, who don't? ;))
Like "Start" section at http://ofbiz.apache.org/download.html and others alike in wiki. Unfortunately you can only make 1 1st impression. Of course,
we possibly could give them an UI for that but we should at least change (all) our documentation.

And even if we agree on this, the main part of the work remains: some components should not be "commented out".

 1. AFAIK example and exampleext does not override anything and they are useful (at least to me), notably in official demo.
 2. Obviously, as it was in R13.07, ecommerce. But not sure the ecommerce component does not override applications...
 3. The POS is not concerned: not used in official demos, does not override anything.
 4. I wonder about the WepPos, does it overrides something, I don't think so but not sure
 5. Several persons spoke about the project manager, not sure it overrides applications.

So the 1st step should be to clearly identify which components are concerned.

Jacopo said <<the default demo of OFBiz will only showcase the more specialized behaviors>> We could have all released demos not using some
specialpurpose components but trunk with all? It's bleeding edge after all.

Jacques

Le 21/11/2015 13:07, [hidden email] a écrit :

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

Reply | Threaded
Open this post in threaded view
|

Re: [Proposition] deactivate by default all specialpurpose component

Ron Wheeler
Would it be possible create a graphic in the docs identifying what
overrides what as you find this out?
A description would be great but at least a visual summary would help
the next person.

Ron

On 24/11/2015 8:31 AM, Jacques Le Roux wrote:

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


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

12