Re: [Proposition] deactivate by default all specialpurpose component

It seems that this discussion is just dancing around the core problem with the current structure of OFBiz. There seems to be a natural set of almost separate projects that are lumped together into a rather tangled object. This discussion is nibbling around the edge of the problem rather than

Re: [Proposition] deactivate by default all specialpurpose component

Hi Ron, It's interesting, and I agree with you we must organise the project and ourselves "more". But it's too early for me at the moment :/ Sorry but I prefer to keep focused on simple tasks (baby steps) for now, this one is about specialpurpose components :) Note that another baby step we

Re: [Proposition] deactivate by default all specialpurpose component

On 14/12/2015 4:40 PM, Jacques Le Roux wrote: Hi Ron, It's interesting, and I agree with you we must organise the project and ourselves "more". But it's too early for me at the moment :/ Sorry but I prefer to keep focused on simple tasks (baby steps) for now, this one is about specialpurpose

Re: [Proposition] deactivate by default all specialpurpose component

Le 08/12/2015 20:59, Nicolas Malin a écrit : Le 19/11/2015 11:45, Jacques Le Roux a écrit : Could we list, apart the well known Birt issue, special components which are overriding main applications? Directly by memory, the scrum components has defined new seca on cust request to send email

Re: [Proposition] deactivate by default all specialpurpose component

Le 19/11/2015 11:45, Jacques Le Roux a écrit : Could we list, apart the well known Birt issue, special components which are overriding main applications? Directly by memory, the scrum components has defined new seca on cust request to send email that break the standard customer request

Re: [Proposition] deactivate by default all specialpurpose component

Sorry Nicolas, I'm not sure I totally get your points :) Could you elaborate please? Thanks Jacques Le 03/12/2015 23:33, Nicolas Malin a écrit : Jacques I understand. We can find a compromise if each specialpurpose components would be identify by meta-data like : demo, util, contrib,

Re: [Proposition] deactivate by default all specialpurpose component

Le 05/12/2015 13:47, Pierre Smits a écrit : I suggest to fix such with separate JIRA issues for each. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Thu, Dec 3, 2015 at 11:05 PM, Nicolas Malin wrote: Le 19/11/2015

Re: [Proposition] deactivate by default all specialpurpose component

I suggest to fix such with separate JIRA issues for each. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Thu, Dec 3, 2015 at 11:05 PM, Nicolas Malin wrote: > Le 19/11/2015 11:45, Jacques Le Roux a écrit : > >> Could we

Re: [Proposition] deactivate by default all specialpurpose component

Jacques I understand. We can find a compromise if each specialpurpose components would be identify by meta-data like : demo, util, contrib, buisness specific to help the end user to load ofbiz with some component like he can load the data with load-seed or load-demo. But it's a second big

Re: [Proposition] deactivate by default all specialpurpose component

Le 19/11/2015 11:45, Jacques Le Roux a écrit : Could we list, apart the well known Birt issue, special components which are overriding main applications? Directly by memory, the scrum components has defined new seca on cust request to send email that break the standard customer request system

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

We know you like visual graphics ;) And it's a good idea! Jacques Le 24/11/2015 15:40, Ron Wheeler a écrit : Would it be possible create a graphic in the docs identifying what overrides what as you find this out? A description would be great but at least a visual summary would help the next

Re: [Proposition] deactivate by default all specialpurpose component

The old joke: Why is it more important for women to be beautiful than smart? Because men see better than they think! If you need any help, let me know. Ron On 24/11/2015 10:37 AM, Jacques Le Roux wrote: We know you like visual graphics ;) And it's a good idea! Jacques Le 24/11/2015 15:40,

Re: [Proposition] deactivate by default all specialpurpose component

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 > wrote: > > I'd veto something which would blindly

Re: [Proposition] deactivate by default all specialpurpose component

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, wrote: > Hi Jacopo, > > I would make a distinction

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

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

Re: [Proposition] deactivate by default all specialpurpose component

Hi Nicolas, I like your proposal. Jacopo On Mon, Nov 9, 2015 at 10:40 PM, Nicolas Malin 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

Re: [Proposition] deactivate by default all specialpurpose component

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

[Proposition] deactivate by default all specialpurpose component

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