OK, I sent this message before seeing Mathieu's last one. I guess the revert Mathieu should close this discussion. I suggest to create a new one about
feature forking (please stop this one).
I must say I'm strongly against feature forking. I have already explained myself why several times. I can reiterate if needed. Mostly for the same
reason Mathieu already exposed in his last message actually.
For the new feature itself, it seems wise to me to have it working with
component-load.xml files before starting it on the trunk...
Thanks
Jacques
Le 18/12/2019 à 12:09, Jacques Le Roux a écrit :
Hi,
In this thread I superficially see a conversation where no one listens to
anyone else's point of view.
If I dig a bit more I see Mathieu's perspective who wants to achieve something
new which depends on the discussed subject (his [1] below).
And Michael's perspective who worries about custom projects in production.
Those are facts, now let's analyse each last main arguments.
Mathieu asks Michael to provide an "explanation regarding why it matters in
production environments to be able to patch" component-load.xml files
Michael does not answer this question but reiterate a question Mathieu did not answer
yet: "is [this] tested working [together] with component-load.xm"
I believe these points must be answered before we get further in this discussion
Jacques
Le 18/12/2019 à 09:17, Michael Brohl a écrit :
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,
Michael
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.
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
