Hi Michael,
First I must say that I understand your POV about production and custom projects. I have been there too and when your business depends on it, things
really matter.
That's why I suggested that we could have both solutions in parallel for a while. With the current one being deprecated and the new one replacing it
w/o hurry. So the 1st question is to know if that's possible. I could be wrong, but I vaguely recall that Mathieu said it was possible. Once that
clarified the debate should cool down.
Before answering to Mathieu's last message, I'd like to note inline some points
about yours.
Le 04/01/2020 à 15:47, Michael Brohl a écrit :
Hi Mathieu,
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)
Here I agree about Mathieu's perspective (in his last email). If an applications component can easily be put out by commenting out the load-component
entry, it should not be in application but in plugins. Only mandatory applications should be in under the applications directory.
* addition of components (yes, I've seen projects where this was not
done through the hot-deploy mechanism)
This is no good and should not be done this way
* ordering these components in the right load order
While 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.
As I said earlier I agree about 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.
Is this not the main reason about your concerns on Mathieu's changes? Can't
this be migrated using Mathieu's proposed solutions?
My proposal would be to actively ask other contributors with significant
project experience for their input before re-commiting anything.
I don't see any problems about committing new stuff as long as they don't disturb current functional behaviours. Note that those should be done in
trunk, and we are not supposed to use the trunk in production. So the impact should not be for today. If we refer to our current stable version it
would be at least 3 years before those being released... Would that not be a reasonable deprecation period?
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.
That sounds reasonable to me
This would introduce the new depends-on in the next release
It would not be the next release, but one in at least 3 years...
but does not change anything for existing users if they want to stick with the
component-load mechanism.
Here we need to know if the cost of maintaining both solutions is worth it. At some point a deprecated mechanism can be removed if the newer solutions
offers more flexibility, better code, etc.
For the plugins, I object to introduce the mechanism at all for the above
stated reasons.
Could you elaborate on that, I don't get it
Thanks
Jacques
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 <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
