Hi Mathieu,citing myself from the comment in https://issues.apache.org/jira/browse/OFBIZ-11296:
Mathieu Lirzin, please consider that people have limited time and that they have to put priorities on how they spent it. Putting pressure on (non bugfixing) issues does not help good collaborations.
Please also refrain to put judgements in your statements like "why they consider to mess with..." or else. Simply trust people who are around for a long time and have deep, real life project experience with OFBiz for a long time (for me it's coming to about 18 years now).
This project is not only about tech, it has a user base with serious business running on base of OFBiz. This has always to be considered as serious as good technical solutions should be considered. So we cannot simply change things because single contributors like other technical solutions better. We have to remain downwards compatible and manage deprecation of features carefully.
Until now, there was not a single thumbs up from experienced contributors for this change, but objections from others. This alone should make you think about your approach.
Me fighting for the right approach also does not necessarily mean that I have (current) personal or customer interests in mind. The user base is much bigger than "my" user base.
If you read carefully what I previously wrote, there are several uses for the applications component-load.xml:
* deactivation of unused component(s) by commenting out the load-component entry (why load marketing resources if you don't use the component at the moment) * addition of components (yes, I've seen projects where this was not done through the hot-deploy mechanism) * ordering these components in the right load orderWhile you can argument that these might be "wrong" approaches, they are technically valid and used in customer projects. Therefore we cannot simply switch the mechanisms without a proper deprecation period.
For the plugins, all the above use cases are common in our projects. We also use a multi-level configuration mechanism (standard default - custom standard default - project default and targeted systems) where we are able to do fine-grained configurations and generate the resulting component-load.xml at build time.
My proposal would be to actively ask other contributors with significant project experience for their input before re-commiting anything.
If there is a demand for yur solution, I would also propose to make the solution compatible with the component-load mechanism and leave the old component-load.xml in place, together with a deprecation announcement and proper documentation on how to migrate. This would introduce the new depends-on in the next release but does not change anything for existing users if they want to stick with the component-load mechanism.
For the plugins, I object to introduce the mechanism at all for the above stated reasons.
I hope this explains my point of view clear enough, please ask if it does not.
Thanks, Michael Am 14.12.19 um 00:28 schrieb Mathieu Lirzin:
Hello Michael, Michael Brohl <[email protected]> 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
