Hello Mathieu, Michael, All I was involved in some of the biggest changes in the framework (gradle, unit tests, start component, core framework, etc ...) and every time it involved a good deep discussion on the mailing list trying to reach consensus before implementation.
So I recommend always treading carefully when doing larger changes and getting others involved. Sometimes people surprise you with better or simpler solutions if you give them the opportunity to express their opinion. Now regarding completely replacing the component-load.xml with depends-on, I'm not sure this makes much sense at the core framework level for a few reasons: - First I don't think this issue is linear. It is possible for example, to speed up the startup time of the system by running things in parallel where possible - Also, the multi-threaded portion of the system (some of it using the executor framework in java.util.concurrent) needs to be studied carefully to see how the loading sequence is best optimized - Finally, I'm just not convinced of either approach (depends-on or container-load) for core framework functionality. We need a better solution that handles the core quite differently (without the need for a component concept). So a better refactoring IMHO on the core level involves an architecture that does not necessarily comply with the component concept, and we can proceed with the original plan of further breaking down the system into a core deplorable framework, core components, and plugins. On Sun, Dec 8, 2019 at 5:30 PM Michael Brohl <michael.br...@ecomify.de> wrote: > > Hi Mathieu, > > I was in fact asking for the discussion and review process to the > changes already introduced and committed in the mentioned Jira. > > It's a good approach to let fellow committers review such work before it > gets committed to the codebase. > > This change will affect existing productive installations and should not > be made without proper documentation and clear instructions for the user > on how to migrate their installation to the new mechanism. > > To me it is not clear what we are gaining with this change. We are > removing one tag which is used and stable for years and introduce > another one which was not used before. Users are forced to migrate their > installations if they had custom modifications. > > I did not look deeply into the changes yet but it looks strange that a > component like "product" or "order" only depends on "humanres". In fact, > they have more dependencies like "party". Given that "depends-on" really > means what it says and has a real difference to the component-load.xml > approach. > > The component-load.xml mechanism clearly shows the loading order of the > components which is an advantage over the cluttered information of the > depends-on mechanism. You will have to analyze every ofbiz-component to > see what's going on. > > IMO these examples show that is in fact worth a discussion and should > not be a lone decision of a single committer. > > I would like to see this being reverted and proposed for discussion and > review before this is going to be introduced into the codebase. > > Thanks you, > > Michael > > > Am 08.12.19 um 13:13 schrieb Mathieu Lirzin: > > > Hello Michael, > > > > Michael Brohl <michael.br...@ecomify.de> writes: > > > >> can you please point me to the discussion where this important change > >> was discussed before it was introduced? > >> > >> I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296 > >> which was closed only hours after it was created. > > If you speak about the usage of <depends-on> in the “framework” and > > “applications” directory, See my response in OFBIZ-11296 regarding what > > has actually changed. > > > > Regarding what I am proposing in this email, I did not open a Jira yet > > and did not commit anything removing the “component-load.xml” feature. > > > > Sorry if I was not explicit enough about the fact that this is a > > discussion not a report of things already changed. > > > >> Am 08.12.19 um 02:34 schrieb Mathieu Lirzin: > >> [...] > >> > >>> In order to simplify things which helps the endeavour towards > >>> transforming OFBiz in an extensible JVM based library, I would like to > >>> remove such configuration point and hard-code the list of component > >>> directories inside the code. > >>> > >>> [...] > >>> > >>> If nobody step-up in a week, I will go ahead. > >>> > >>> Thanks. > >>> >
