[
https://issues.apache.org/jira/browse/OFBIZ-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008054#comment-17008054
]
Michael Brohl edited comment on OFBIZ-11296 at 1/5/20 9:17 AM:
---------------------------------------------------------------
[~mthl], please consider that people have limited time and that they have to
put priorities on how they spent it. Putting pressure on (non bugfixing) issues
does not help good collaborations.
Please also refrain to put judgements in your statements like "why they
consider to mess with..." or else. Simply trust people who are around for a
long time and have deep, real life project experience with OFBiz for a long
time (for me it's coming to about 18 years now).
This project is not only about tech, it has a user base with serious business
running on base of OFBiz. This has always to be considered as serious as good
technical solutions should be considered. So we cannot simply change things
because single contributors like other technical solutions better. We have to
remain downwards compatible and manage deprecation of features carefully.
Until now, there was not a single thumbs up from experienced contributors for
this change, but objections from others. This alone should make you think about
your approach.
Me fighting for the right approach also does not necessarily mean that I have
(current) personal or customer interests in mind. The user base is much bigger
than "my" user base.
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)
* addition of components (yes, I've seen projects where this was not done
through the hot-deploy mechanism)
* 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.
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.
My proposal would be to actively ask other contributors with significant
project experience for their input before re-commiting anything.
If there is a demand for your 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. This would introduce the new depends-on
in the next release but does not change anything for existing users if they
want to stick with the component-load mechanism.
For the plugins, I object to introduce the mechanism at all for the above
stated reasons.
I hope this explains my point of view clear enough, please ask if it does not.
was (Author: mbrohl):
[~mthl], please consider that people have limited time and that they have to
put priorities on how they spent it. Putting pressure on (non bugfixing) issues
does not help good collaborations.
Please also refrain to put judgements in your statements like "why they
consider to mess with..." or else. Simply trust people who are around for a
long time and have deep, real life project experience with OFBiz for a long
time (for me it's coming to about 18 years now).
This project is not only about tech, it has a user base with serious business
running on base of OFBiz. This has always to be considered as serious as good
technical solutions should be considered. So we cannot simply change things
because single contributors like other technical solutions better. We have to
remain downwards compatible and manage deprecation of features carefully.
Until now, there was not a single thumbs up from experienced contributors for
this change, but objections from others. This alone should make you think about
your approach.
Me fighting for the right approach also does not necessarily mean that I have
(current) personal or customer interests in mind. The user base is much bigger
than "my" user base.
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)
* addition of components (yes, I've seen projects where this was not done
through the hot-deploy mechanism)
* 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.
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.
My proposal would be to actively ask other contributors with significant
project experience for their input before re-commiting anything.
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. This would introduce the new depends-on
in the next release but does not change anything for existing users if they
want to stick with the component-load mechanism.
For the plugins, I object to introduce the mechanism at all for the above
stated reasons.
I hope this explains my point of view clear enough, please ask if it does not.
> Use 'depends-on' everywhere
> ---------------------------
>
> Key: OFBIZ-11296
> URL: https://issues.apache.org/jira/browse/OFBIZ-11296
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
> Affects Versions: Trunk
> Reporter: Mathieu Lirzin
> Assignee: Mathieu Lirzin
> Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments:
> OFBIZ-11296_0001-Improved-Use-depends-on-attribute-instead-of-compone.patch,
> OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch
>
>
> We currently have two ways to define component loading order. Either
> by using ‘depends-on’ attribute in “component-config.xml” or by adding
> a “component-load.xml” file at the root of a component directory.
> “depends-on” is more flexible because it handles partial ordering when
> “component-load.xml” defines a total order which is not necessarily
> meaningful, so it is better to rely only “depends-on”.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
