Hello Michael, Michael Brohl <michael.br...@ecomify.de> writes:
> 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. This need is practical because when I speak about *things* that seems blocking for people, I can't just continue to implement the next step of those *things* in parallel by ignoring people input, so I am effectively blocked by this discussion. > 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 I have told you multiple times that this was not my interpretation of what happened. I would have appreciated if your interpretation could be expressed in a modularized way meaning that this is your interpretation not a proven fact. > * you did not answer my questions if this is tested working togehther > with component-load.xml To be honest I intentionnally ignored this question to keep the discussion positive and constructive, because in the same paragraph you were asking for unreasonable things by stating “It is not my responsibility to prove that it is not working, it is yours to prove that it works.” which as every serious software developper know is impossible unless a formal proof [1] is provided which is unrealistic in OFBiz context. I did not explicitly test the scenario you described because I am still unable to see even after asking you multiple times for an explanation and more context, why this scenario matters. Because Samuel is a nice and constructive person, he has tried the described scenario, and discovered that there is actually a regression in [3] meaning that “component-load.xml” does not fully override the <depend-on> declarations. So for your pleasure the commit is going to be reverted. \o/ > PS: 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. That is an option, however creating a feature branch has trade-offs, meaning the longer it stays alive the more difficult it becomes mergeable. My impression is that a feature branch for the “Location independent extension mechanism” work [2] will necessarly be long-lived with a lot of impact in the framework. As a consequence that branch will quickly be unmergeable and become effectively a fork. As a consequence I would rather prefer to keep the active development of [2] in trunk to avoid creating a fork. My understanding is that the big changes that Taher introduced some years ago (Plugins, Gradle, Startup) were done with overall community consensus on trunk, but maybe I am overlooking some important details. [1] https://en.wikipedia.org/wiki/Computer-assisted_proof [2] https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E [3] https://github.com/apache/ofbiz-framework/commit/eeabe69813a1d9f42911dec70a912574046ef49b -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
