Hello, @Michael: I would like to know if you intend to provide an explanation regarding why it matters in production environments to be able to patch “framework/component-load.xml” and “applications/component-load.xml” ? This would help determining what should be done regarding [1] (meaning documentation, reverting, migration guide, ...). Sorry if I am pressing you but I need that the discussion moves forward.
If not I would like to refocus the discussion on the next step which is about the propositions of: 1. Removing “base/config/component-load.xml” and hard-code the ["framework", "themes", "applications", "plugins"] sequence with the new requirement that extensions must be done inside “plugins” as long as we don't have a location-independent extension mechanism [2]. 2. Removing the “component-load.xml” feature which provides a mechanism to define an arbitrary order for a set of components inside a directory to bypass the “smart loading” derived from functional component dependency declarations. This removal is a pre-requisite to implement a location-independent extension mechanism [2]. Are there any objection regarding those 2 propositions ? [1] https://github.com/apache/ofbiz-framework/commit/eeabe69813a1d9f42911dec70a912574046ef49b [2] https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E Mathieu Lirzin <mathieu.lir...@nereide.fr> writes: > Michael Brohl <michael.br...@ecomify.de> writes: > >> I am still not sure why we need the new mechanism. >> >> And if we decide to use both, we should make sure that the old version >> is the default at least for the lifecycle of one release with proper >> an clear dopcumentation for users. >> >> Thanks, >> >> Michael >> >> >> PS: I'm asking myself why some people have such a big problem >> reverting their work if others object against it. If there was no >> review/discussion/consensus for a new feature, it should simply not go >> into the codebase and should at least be reverted if there are >> objections. >> >> It's tiring to discuss this afterwards and if the people objecting are >> not persistent enough, the code simply stays. > > I have personally no problem reverting things. If you look at the ‘git > log’ you will see some recent reverts I have made. I just need to > understand the actual objection before reverting [1]. > > Since your argument seems to be about the “impacts on users” an > explanation regarding what you or others are actually achieving when > patching the “framework/component-load.xml” and > “applications/component-load.xml” would help me understand the issue, > because I honestly do not see why the loading order/mechanism of > “framework” or “applications” should not be considered an implementation > detail. > > By the way to give more context on my perspective, the usage of > <depends-on> instead of “component-load.xml” in the > framework/applications directories is related to the implementation of > the work described in a previous discussion [2] because it defines a > location independent an extensible component loading order. > > HTH, > > [1] > https://github.com/apache/ofbiz-framework/commit/eeabe69813a1d9f42911dec70a912574046ef49b > [2] > https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
