Hi Mathieu, inline...
Am 18.12.19 um 00:01 schrieb Mathieu Lirzin:
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.
Why do you "need that discussion moves forward"? I do not see any reason to hurry.
In my view, you still did not explain sufficiently why we need this change. I summarize:* you introduced a *new* mechanism with the goal to remove a field tested one
* it does not provide any new functionality, better readability or fixes a bug
* it forces users to fix their existing installations once they use a new release with this change
* you did not answer my questions if this is tested working togehther with component-load.xml
Additionally, there was not even one committer who supports your approach yet, while there is one strong objection by me and some doubts expressed by Taher.
So, before moving forward in this direction we should first hear some opinions by others about this change and the general plans.
Fellow devs and users, please give your opinions so that we can decide upon different points of view.
Thanks, MichaelPS: I'd suggest to open a feature branch with the changes and upcoming changes. This removes pressure to get things into the trunk just to move forward and would allow the community to study the approach without the downside to break anything in trunk before the solution is worked out as a whole.
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
smime.p7s
Description: S/MIME Cryptographic Signature
