Hi, everybody, It is not easy to add something in the discussion among the different arguments! (and on the different topics)
I will, however, try to give some summary of my position on the various subjects discussed. 1) As Jacques recall "Community over code" so : 1.1 : It is important to trust all the members of the community in their will to improve OFBiz 1.2 : the discussion cannot take place in 2 or 3 days, it is rather in a week or a month that it will take place. (I don't have 2 or 3 hours to read (and answer) the mail every day, but I can find them during a week.. This is an advantage of mailing list discussions over chat discussions. 2) Deprecated (with documentation) before removing is a very good solution, in a release migration process, when something has disappears (not yet move to the new solution), it's more easy to retrieve file when it was deprecated to read associated documentation and know how to migrate. the rule is the same even it's simple util java method ;-) 3) I clearly not understand all implications/advantages/constrains ... or whatever about depend-on or component-load what I only can be say is : In a functional consultant point of view which want to configure an ofbiz with a lot of plugins (between 20 and 40) it's more easy to have a depend-on on each plugin to be sure the loading order will be correct. 4) implementation detail or core choice, often, it's depend of point of view you use On ERP development / implementation there are multiple type of people working on it with each one, specifics knowledge, usage, practice and point of view. When someone says, it's a big change, start by trusting him and find out which process is affected to propose a solution; he doesn't want to block something, he wants to help you come up with a better solution that solves more cases. 5) patching is wrong : very often there are patch because hook or extend mechanism not exist so When a plugin contains a patch, framework expert should explain or how to use existing extensibility mechanism to avoid the patch or how to improve the framework to provide a extensibility mechanism for this case this point is also an example about previous point ;-) 6) what is OFBiz, - not only a public API ;-) - not only a framework - currently not a OOTB ERP but I hope what, in future, there will contain some OOTB applications In my long term view Apache OFBiz could be like linux, a core/kernel as small as possible with multiple components (the plugins) and so with some distributions. So, clearly, for me it is not possible to define the boundary between what is public (with backward compatibility) and what is only implementation. Even on data model I can give some examples where not everyone will agree on what is in kernel and what is in components just my 6 cents Olivier Le 06/01/2020 à 10:29, Samuel Trégouët a écrit : > > I also hope others contributors will eventually join (many thanks to > Jacques for joining!) since this discussion seems to me to be larger > than a particular feature (component-load.xml): it is about the process > of contributing to OFBiz. > >
