Hello, Michael Brohl <michael.br...@ecomify.de> writes:
> Am 31.01.20 um 13:15 schrieb Jacques Le Roux: >> >> We 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 description is dishonest, I have always opened discussions on this mailing-list and waited for feedback when considering a *big/breaking change*. I have only moved fast when I considered that what I was working on was an implementation detail and that the improvement was obvious. The actual issue is not that I did not follow the rules. The fact that I ended up opening/closing a JIRA the same day I commit things that I consider trivial was precisely to conform to the policy of “every change needs to have a JIRA associated” which is bureaucratic non-sense. The actual issue is that in the case of “{framework,applications}/component-load.xml” we disagreed on the trivial aspect of this change. This disagreement is an expected thing because nobody in this community can tell the difference between an *implementation detail* and a *breaking change* because we don't have (and don't want) a public API. This simply means that every code change is a breaking change and that it should follow a slow process of review to let evaluate the trade-offs between potential downstream breakage (that we might not be aware of) and the actual benefits of the proposed change. > 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. I am glad that you appreciate the initiative, but as far as I am concerned I am certainly not enjoying my time in this community anymore. >> 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). Basically you are acknowledging that nobody cares deeply about the idea I proposed in previous thread (which is probably true) but at the same time you are suggesting me to write a lengthy design/architectural document that will rephrase what as already been said in that thread. Sorry but no, I will not write such document, I have already explained multiple times the design principles leading to the proposal of enabling the distribution of OFBiz inside a Jar: - Extensible dependency management is better than having to define a arbitrary global ordering - Location independent loading/configuration mechanism is the only sane way to provide true extensibility. - Adopting the stable mechanism provided by the Java platform that we already depend on is better than implementing our own specific mechanism If people are not convinced by the benefits of this vision which imply deprecating the “component-load.xml” mechanism and use “depends-on” instead (which I did not introduced in the first place) then providing a precise design/implementation plan will not help moving forward, it will just lead to more time waste on my side. I don't see the point of continuing this unproductive discussion neither to proceed with a formal vote regarding the deprecation of “component-load.xml”, because whatever the result I have lost my faith in the capability of this community to succeed at handling the technical challenges that will enable OFBiz to stay relevant in the future. But this is fine.
-- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
