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, <slidingfilame...@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.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 > >>>>> > >>>>> > >>>>> >
