Hi Jacques, inline...
Am 31.01.20 um 13:15 schrieb Jacques Le Roux:
Hi Michael Le 31/01/2020 à 11:15, Michael Brohl a écrit :Hi Jacques, inline... Am 31.01.20 um 10:06 schrieb Jacques Le Roux:2. Remove component-load.xml from applications and plugins. As it's an issue for the external use the deprecation process is needed.This will need thorough discussion of all the pros and cons *before* we take action on this. I feel this needs more discussion and awareness of other community members and users.A summary of the pros and cons would help making it easier for others to decide.And, most important, the big plan behind this should be laid out so that we have a chance to understand why this would be important.MichaelWe have already 2 sources for that The reasons it's planned: https://s.apache.org/7e590We could continue the discussion in this thread or at https://issues.apache.org/jira/browse/OFBIZ-11296
This issue shows exactly the same pattern in the process like the component-load approach. The Jira was created and *on the same day* the first patches were committed without further discussion within the Jira. The Jiras contains a link to a discussion with the statement "this has been discusses on Development mailing list".
In fact, the thread also started on the same day in dev but has not many reactions and in no way any decision to go in that direction. This is by no means the correct way to introduce fundamental changes to the project.
This is a huge and complex topic, not only on a technical level. This needs a real concept to give everyone the chance to really understand which consequences these changes will have. There are always pros and cons for every solution and I am pretty sure that the consequences cannot be overseen by single contributors and without the exchange between a significant amount of experienced OFBiz contributors.
I'm also pretty sure that, if the community decides to go that way after a thorough exchange of arguments and real life practical experience, the implementation will be a long-running project itself. This cannot be undertaken on the trunk but will need a feature branch, which has to be discussed when the time is right.
As much as I appreciate the initiative to move things forward I am also strictly against the approach and process to put fundamental changes into the codebase without through conceptual work and planning.
https://issues.apache.org/jira/browse/OFBIZ-11161 is also related Maybe better to create a new thread?
We already have a thread for it, started on 22. August 2019. I would very much appreciate if experienced users/developers would join this discussion (which I have missed being on vacation at the time and, having not much response, did not get my attention until now).
HTH Jacques
Thanks, Michael
smime.p7s
Description: S/MIME Cryptographic Signature
