ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: [Proposition] deactivate by default all specialpurpose component
Date Tue, 24 Nov 2015 13:31:16 GMT
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.


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<jacques.le.roux@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,<slidingfilaments@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
>>>>> 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
>>>>>> 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
>>>> steps
>>>>>>> in the direction of having a lean lightweight framework with
>>>>>>> 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
>>>>>>> "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
>>>>>>> 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
>>>>>>> for
>>>>>>> one specific industry only.
>>>>>>> Nicolas' proposal addresses this issue and still leaves the ability
>>>> 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
>>>> 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
>>>> its
>>>>>>>> architecture. We need a _plugin_ implementation that achieves
>>>>>>>> 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
>>>> Take a
>>>>>>>> look at this thread <
>>>> http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
>>>>>>>> in
>>>>>>>> which we discussed this issue and suggested one of several
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>>> or
>>>>>>>>> $ ant load-component -D"components=ecommerce projectmgr
>>>>>>>>> load-demo start
>>>>>>>>> This help beginner through easy command line to copy/past
>>>>>>>>> documentation or expert by scripting to configure ofbiz.
>>>>>>>>> Nicolas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message