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.cappell...@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.r...@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 <
>>> slidingfilame...@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.ma...@nereide.fr>
>>>> wrote:
>>>> 
>>>> Le 10/11/2015 05:54, slidingfilame...@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
>>>>> 
>>>>> 
>>>>> 

Reply via email to