Removing “base/config/component-load.xml”

[Mathieu Lirzin]

Hello,

We have in OFBiz two redundant ways to define the order in which
components are loaded.

* “component-load.xml” files stored in components directories meaning
  directories containing single components. They define a total order
  between every component inside that directory.

* <depends-on> XML elements inside “ofbiz-component.xml” files stating
  that a component ‘c’ requires a set of components ‘D’ to exist and to
  be loaded before trying to load ‘c’.  Globally this constructs a
  dependency graph which defines a partial order between available
  components.

Currently <depends-on> is used everywhere in the framework on ‘trunk’
because it is more declarative and open for extensibility due the
partial ordering capability.

The only exception is “base/config/component-load.xml” which is a
special components directory configuration defining the order of other
components directories meaning “framework”, “themes”, “applications” and
“plugins” in their respective dependency order.

This file allows integrators to add and reorder components
directories. This feature is not really useful nowadays considering that
our plugin mechanism provides sufficient extensibility capability when
combined with <depends-on> definitions.

In order to simplify things which helps the endeavour towards
transforming OFBiz in an extensible JVM based library, I would like to
remove such configuration point and hard-code the list of component
directories inside the code.

I guess this low-level technical proposition is not interesting for most
people but in case someone want to understand more or object before
things are actually removed. I am opening a discussion on this ML.

If nobody step-up in a week, I will go ahead.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Michael Brohl-3]

Hi Mathieu,

can you please point me to the discussion where this important change
was discussed before it was introduced?

I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296 
which was closed only hours after it was created.

I was a bit off lately, maybe I missed something.

Thank you,

Michael


Am 08.12.19 um 02:34 schrieb Mathieu Lirzin:

> Hello,
>
> We have in OFBiz two redundant ways to define the order in which
> components are loaded.
>
> * “component-load.xml” files stored in components directories meaning
>    directories containing single components. They define a total order
>    between every component inside that directory.
>
> * <depends-on> XML elements inside “ofbiz-component.xml” files stating
>    that a component ‘c’ requires a set of components ‘D’ to exist and to
>    be loaded before trying to load ‘c’.  Globally this constructs a
>    dependency graph which defines a partial order between available
>    components.
>
> Currently <depends-on> is used everywhere in the framework on ‘trunk’
> because it is more declarative and open for extensibility due the
> partial ordering capability.
>
> The only exception is “base/config/component-load.xml” which is a
> special components directory configuration defining the order of other
> components directories meaning “framework”, “themes”, “applications” and
> “plugins” in their respective dependency order.
>
> This file allows integrators to add and reorder components
> directories. This feature is not really useful nowadays considering that
> our plugin mechanism provides sufficient extensibility capability when
> combined with <depends-on> definitions.
>
> In order to simplify things which helps the endeavour towards
> transforming OFBiz in an extensible JVM based library, I would like to
> remove such configuration point and hard-code the list of component
> directories inside the code.
>
> I guess this low-level technical proposition is not interesting for most
> people but in case someone want to understand more or object before
> things are actually removed. I am opening a discussion on this ML.
>
> If nobody step-up in a week, I will go ahead.
>
> Thanks.
>

[Mathieu Lirzin]

Hello Michael,

Michael Brohl <[hidden email]> writes:

> can you please point me to the discussion where this important change
> was discussed before it was introduced?
>
> I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296
> which was closed only hours after it was created.

If you speak about the usage of <depends-on> in the “framework” and
“applications” directory, See my response in OFBIZ-11296 regarding what
has actually changed.

Regarding what I am proposing in this email, I did not open a Jira yet
and did not commit anything removing the “component-load.xml” feature.

Sorry if I was not explicit enough about the fact that this is a
discussion not a report of things already changed.

> Am 08.12.19 um 02:34 schrieb Mathieu Lirzin:
> [...]
>
>> In order to simplify things which helps the endeavour towards
>> transforming OFBiz in an extensible JVM based library, I would like to
>> remove such configuration point and hard-code the list of component
>> directories inside the code.
>>
>> [...]
>>
>> If nobody step-up in a week, I will go ahead.
>>
>> Thanks.
>>
>

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Michael Brohl-3]

Hi Mathieu,

I was in fact asking for the discussion and review process to the
changes already introduced and committed in the mentioned Jira.

It's a good approach to let fellow committers review such work before it
gets committed to the codebase.

This change will affect existing productive installations and should not
be made without proper documentation and clear instructions for the user
on how to migrate their installation to the new mechanism.

To me it is not clear what we are gaining with this change.  We are
removing one tag which is used and stable for years and introduce
another one which was not used before. Users are forced to migrate their
installations if they had custom modifications.

I did not look deeply into the changes yet but it looks strange that a
component like "product" or "order" only depends on "humanres". In fact,
they have more dependencies like "party". Given that "depends-on" really
means what it says and has a real difference to the component-load.xml
approach.

The component-load.xml mechanism clearly shows the loading order of the
components which is an advantage over the cluttered information of the
depends-on mechanism. You will have to analyze every ofbiz-component to
see what's going on.

IMO these examples show that is in fact worth a discussion and should
not be a lone decision of a single committer.

I would like to see this being reverted and proposed for discussion and
review before this is going to be introduced into the codebase.

Thanks you,

Michael


Am 08.12.19 um 13:13 schrieb Mathieu Lirzin:

> Hello Michael,
>
> Michael Brohl <[hidden email]> writes:
>
>> can you please point me to the discussion where this important change
>> was discussed before it was introduced?
>>
>> I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296
>> which was closed only hours after it was created.
> If you speak about the usage of <depends-on> in the “framework” and
> “applications” directory, See my response in OFBIZ-11296 regarding what
> has actually changed.
>
> Regarding what I am proposing in this email, I did not open a Jira yet
> and did not commit anything removing the “component-load.xml” feature.
>
> Sorry if I was not explicit enough about the fact that this is a
> discussion not a report of things already changed.
>
>> Am 08.12.19 um 02:34 schrieb Mathieu Lirzin:
>> [...]
>>
>>> In order to simplify things which helps the endeavour towards
>>> transforming OFBiz in an extensible JVM based library, I would like to
>>> remove such configuration point and hard-code the list of component
>>> directories inside the code.
>>>
>>> [...]
>>>
>>> If nobody step-up in a week, I will go ahead.
>>>
>>> Thanks.
>>>

[taher]

Hello Mathieu, Michael, All

I was involved in some of the biggest changes in the framework
(gradle, unit tests, start component, core framework, etc ...) and
every time it involved a good deep discussion on the mailing list
trying to reach consensus before implementation.

So I recommend always treading carefully when doing larger changes and
getting others involved. Sometimes people surprise you with better or
simpler solutions if you give them the opportunity to express their
opinion.

Now regarding completely replacing the component-load.xml with
depends-on, I'm not sure this makes much sense at the core framework
level for a few reasons:

- First I don't think this issue is linear. It is possible for
example, to speed up the startup time of the system by running things
in parallel where possible
- Also, the multi-threaded portion of the system (some of it using the
executor framework in java.util.concurrent) needs to be studied
carefully to see how the loading sequence is best optimized
- Finally, I'm just not convinced of either approach (depends-on or
container-load) for core framework functionality. We need a better
solution that handles the core quite differently (without the need for
a component concept).

So a better refactoring IMHO on the core level involves an
architecture that does not necessarily comply with the component
concept, and we can proceed with the original plan of further breaking
down the system into a core deplorable framework, core components, and
plugins.

On Sun, Dec 8, 2019 at 5:30 PM Michael Brohl <[hidden email]> wrote:

>
> Hi Mathieu,
>
> I was in fact asking for the discussion and review process to the
> changes already introduced and committed in the mentioned Jira.
>
> It's a good approach to let fellow committers review such work before it
> gets committed to the codebase.
>
> This change will affect existing productive installations and should not
> be made without proper documentation and clear instructions for the user
> on how to migrate their installation to the new mechanism.
>
> To me it is not clear what we are gaining with this change.  We are
> removing one tag which is used and stable for years and introduce
> another one which was not used before. Users are forced to migrate their
> installations if they had custom modifications.
>
> I did not look deeply into the changes yet but it looks strange that a
> component like "product" or "order" only depends on "humanres". In fact,
> they have more dependencies like "party". Given that "depends-on" really
> means what it says and has a real difference to the component-load.xml
> approach.
>
> The component-load.xml mechanism clearly shows the loading order of the
> components which is an advantage over the cluttered information of the
> depends-on mechanism. You will have to analyze every ofbiz-component to
> see what's going on.
>
> IMO these examples show that is in fact worth a discussion and should
> not be a lone decision of a single committer.
>
> I would like to see this being reverted and proposed for discussion and
> review before this is going to be introduced into the codebase.
>
> Thanks you,
>
> Michael
>
>
> Am 08.12.19 um 13:13 schrieb Mathieu Lirzin:
>
> > Hello Michael,
> >
> > Michael Brohl <[hidden email]> writes:
> >
> >> can you please point me to the discussion where this important change
> >> was discussed before it was introduced?
> >>
> >> I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296
> >> which was closed only hours after it was created.
> > If you speak about the usage of <depends-on> in the “framework” and
> > “applications” directory, See my response in OFBIZ-11296 regarding what
> > has actually changed.
> >
> > Regarding what I am proposing in this email, I did not open a Jira yet
> > and did not commit anything removing the “component-load.xml” feature.
> >
> > Sorry if I was not explicit enough about the fact that this is a
> > discussion not a report of things already changed.
> >
> >> Am 08.12.19 um 02:34 schrieb Mathieu Lirzin:
> >> [...]
> >>
> >>> In order to simplify things which helps the endeavour towards
> >>> transforming OFBiz in an extensible JVM based library, I would like to
> >>> remove such configuration point and hard-code the list of component
> >>> directories inside the code.
> >>>
> >>> [...]
> >>>
> >>> If nobody step-up in a week, I will go ahead.
> >>>
> >>> Thanks.
> >>>
>

[Mathieu Lirzin]

Michael Brohl <[hidden email]> writes:

> I was in fact asking for the discussion and review process to the
> changes already introduced and committed in the mentioned Jira.

OK

> It's a good approach to let fellow committers review such work before
> it gets committed to the codebase.

I agree in theory, but given the poor state of the codebase I feel that
requiring that every single change is delayed for 2/3 days or more to
let people review it is not manageable.

The approach I am following in practice is to apply my own judgement to
separate things that are safe and things that need to be discussed
beforehand.

I considered (maybe wrongly) that using <depends-on> in the “framework”
and “applications” components directories was safe because it did not
remove any feature.

> This change will affect existing productive installations and should
> not be made without proper documentation and clear instructions for
> the user on how to migrate their installation to the new mechanism.
>
> To me it is not clear what we are gaining with this change.  We are
> removing one tag which is used and stable for years and introduce
> another one which was not used before. Users are forced to migrate
> their installations if they had custom modifications.

I am confused about what you are talking about because I still don't see
in what has already been committed in ‘trunk’ what is “affecting
productive installations” because the “component-load.xml” feature is
still here and users can still place their existing “component-load.xml”
files and get the same behavior as before.

> I did not look deeply into the changes yet but it looks strange that a
> component like "product" or "order" only depends on "humanres". In
> fact, they have more dependencies like "party". Given that
> "depends-on" really means what it says and has a real difference to
> the component-load.xml approach.

The dependency relation is transitive meaning:

if (x depends on y) and (y depends on z) then (x depends on z).

It is possible to be explicit about the "transitive" dependencies by
declaring them as direct dependencies when the fact that a direct
dependency is depending on another one is an implementation details
which might not hold in the future.

For example: the Gradle plugin “groovy” depends on the Gradle plugin
“java” but there is little chance that the “groovy” plugin will not
depend on the “java” one in the future so it is safe to only declare a
dependency on the “groovy” plugin.

The current dependency declarations in framework/applications is a
direct mapping of the order defined in the previous “component-load.xml”
file which need to be refined because that order lacked information
regarding the actual functional dependencies (which is the inherent
downside of using a total order for partially ordered things).

> The component-load.xml mechanism clearly shows the loading order of
> the components which is an advantage over the cluttered information of
> the depends-on mechanism. You will have to analyze every
> ofbiz-component to see what's going on.

You are correct that “component-load.xml” shows the precise loading
order of components, however it lacks a precise definition of the actual
functional dependencies between components.

You can derive one valid loading order from the set of actual functional
dependencies, however as stated above it is not possible to derive the
functional dependencies from a “component-load.xml” file.

Currently we lack a mechanism to display the global dependency graph
which is important to for example to analyse why a component is loaded
before or after another one.  However this feature should be easy to
implement and could be a requirement before removing the
“component-load.xml” feature.

> IMO these examples show that is in fact worth a discussion and should
> not be a lone decision of a single committer.
>
> I would like to see this being reverted and proposed for discussion
> and review before this is going to be introduced into the codebase.

I have no problem reverting things, however to be legitim your call for
revert should be backed by an actual proof that the “component-load.xml”
feature has been removed (which is not the case) or that the component
loading work has introduced a bug/regression.

So I encourage you to try to backport one of your production
“component-load.xml” on trunk and report a bug if necessary.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Mathieu Lirzin]

Hello Taher,

Taher Alkhateeb <[hidden email]> writes:

> I was involved in some of the biggest changes in the framework
> (gradle, unit tests, start component, core framework, etc ...) and
> every time it involved a good deep discussion on the mailing list
> trying to reach consensus before implementation.
>
> So I recommend always treading carefully when doing larger changes and
> getting others involved. Sometimes people surprise you with better or
> simpler solutions if you give them the opportunity to express their
> opinion.

This is my perspective too, and every time I feel that an improvement I
am considering has a strong impact, I make the effort of sending an
email to this ML explaining the problem and asking for feedback on the
considered solution.

> Now regarding completely replacing the component-load.xml with
> depends-on, I'm not sure this makes much sense at the core framework
> level for a few reasons:
>
> - First I don't think this issue is linear. It is possible for
> example, to speed up the startup time of the system by running things
> in parallel where possible
> - Also, the multi-threaded portion of the system (some of it using the
> executor framework in java.util.concurrent) needs to be studied
> carefully to see how the loading sequence is best optimized
> - Finally, I'm just not convinced of either approach (depends-on or
> container-load) for core framework functionality. We need a better
> solution that handles the core quite differently (without the need for
> a component concept).
>
> So a better refactoring IMHO on the core level involves an
> architecture that does not necessarily comply with the component
> concept, and we can proceed with the original plan of further breaking
> down the system into a core deplorable framework, core components, and
> plugins.

Since you don't like either solutions and given that currently we have
both, wouldn't it be a step forward to get rid of one of them ? :-)

IMO the discussion is not about deciding if separating the framework
core into multiple components is a good idea or not.  We are only
discussing if we should remove the “component-load.xml” feature which
implies removing an historic configuration mechanism that was providing
integrators the capability to use other meta-directories than
"framework", "themes", "applications, "plugins" and to define a total
order between components in component directories.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Michael Brohl-3]

Hi Mathieu,

inline...

>> It's a good approach to let fellow committers review such work before
>> it gets committed to the codebase.
> I agree in theory, but given the poor state of the codebase I feel that
> requiring that every single change is delayed for 2/3 days or more to
> let people review it is not manageable.

This is how community projects work!

If you want to introduce new features or important changes to the
codebase, you will have to propose them and stand the discussion (and
maybe delays of a few weeks if not months). It is the responsibility of
the contributor to prove his solution being a good fit for the project
beforehand.

The quality of code you mentioned partly is a result of times when a few
committers simply forced their changes into the codebase whether the
community liked it or not.

>
> The approach I am following in practice is to apply my own judgement to
> separate things that are safe and things that need to be discussed
> beforehand.

As committers we should act as positive examples on how good community
work should be lived. New features, especially if they have an impact on
the users, should always be discussed beforehand. And if they get
accepted, it should also include a good documentation and migration
guide for the users.


>
> I considered (maybe wrongly) that using <depends-on> in the “framework”
> and “applications” components directories was safe because it did not
> remove any feature.

It *does* remove a feature from a users perspective. The
component-load.xml will be gone and custom enhancements will not work
ootb after the change.

>
>> This change will affect existing productive installations and should
>> not be made without proper documentation and clear instructions for
>> the user on how to migrate their installation to the new mechanism.
>>
>> To me it is not clear what we are gaining with this change.  We are
>> removing one tag which is used and stable for years and introduce
>> another one which was not used before. Users are forced to migrate
>> their installations if they had custom modifications.
> I am confused about what you are talking about because I still don't see
> in what has already been committed in ‘trunk’ what is “affecting
> productive installations” because the “component-load.xml” feature is
> still here and users can still place their existing “component-load.xml”
> files and get the same behavior as before.

See above. Users are driving serious business with the OFBiz platform
and we should have this in mind when we are doing changes to the codebase.

It's not just a technical change, it affects projects, needs migration
testing etc. and therefore it should be discussed thoroughly if this is
a good and needed change.

>
>> I did not look deeply into the changes yet but it looks strange that a
>> component like "product" or "order" only depends on "humanres". In
>> fact, they have more dependencies like "party". Given that
>> "depends-on" really means what it says and has a real difference to
>> the component-load.xml approach.
> The dependency relation is transitive meaning:
>
> if (x depends on y) and (y depends on z) then (x depends on z).
>
> It is possible to be explicit about the "transitive" dependencies by
> declaring them as direct dependencies when the fact that a direct
> dependency is depending on another one is an implementation details
> which might not hold in the future.
>
> For example: the Gradle plugin “groovy” depends on the Gradle plugin
> “java” but there is little chance that the “groovy” plugin will not
> depend on the “java” one in the future so it is safe to only declare a
> dependency on the “groovy” plugin.
>
> The current dependency declarations in framework/applications is a
> direct mapping of the order defined in the previous “component-load.xml”
> file which need to be refined because that order lacked information
> regarding the actual functional dependencies (which is the inherent
> downside of using a total order for partially ordered things).

The current implementation of "depends-on" does also lack information of
functional dependencies because they are not clearly visible at teh
place where they are defined.

IMO it does not improve the transparency of the dependencies better than
the "component-load" approach.

>
>> The component-load.xml mechanism clearly shows the loading order of
>> the components which is an advantage over the cluttered information of
>> the depends-on mechanism. You will have to analyze every
>> ofbiz-component to see what's going on.
> You are correct that “component-load.xml” shows the precise loading
> order of components, however it lacks a precise definition of the actual
> functional dependencies between components.
>
> You can derive one valid loading order from the set of actual functional
> dependencies, however as stated above it is not possible to derive the
> functional dependencies from a “component-load.xml” file.
>
> Currently we lack a mechanism to display the global dependency graph
> which is important to for example to analyse why a component is loaded
> before or after another one.  However this feature should be easy to
> implement and could be a requirement before removing the
> “component-load.xml” feature.
>
>> IMO these examples show that is in fact worth a discussion and should
>> not be a lone decision of a single committer.
>>
>> I would like to see this being reverted and proposed for discussion
>> and review before this is going to be introduced into the codebase.
> I have no problem reverting things, however to be legitim your call for
> revert should be backed by an actual proof that the “component-load.xml”
> feature has been removed (which is not the case) or that the component
> loading work has introduced a bug/regression.

See my statements about community work above.

>
> So I encourage you to try to backport one of your production
> “component-load.xml” on trunk and report a bug if necessary.

Did you test how "depends-on" is working together with the
"component-load" mechanism?

It is not my responsibility to prove that it is not working, it is yours
to prove that it works.


>
> Thanks.
>
Let me say that I really appreciate your work for the project, Mathieu.

I'm simply trying to keep up good community work and feel responsible
for the users of the project, hence my objections.

Thanks,

Michael

[Jacques Le Roux]

Hi Mathieu,

Le 08/12/2019 à 18:27, Mathieu Lirzin a écrit :
> Currently we lack a mechanism to display the global dependency graph
> which is important to for example to analyse why a component is loaded
> before or after another one.  However this feature should be easy to
> implement and could be a requirement before removing the
> “component-load.xml” feature.

In case you did not know, here is a representation of the situation, I guess it may help

https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies

HTH

Jacques

[Jacques Le Roux]

Hi Michael, Mathieu,

Why not keeping both features and have a simple way (if it does not exist yet) to choose the one to use?

BTW Michael,  you are certainly aware, you have a mail certificate issue.

Thanks

Jacques

Le 09/12/2019 à 08:08, Michael Brohl a écrit :

> Hi Mathieu,
>
> inline...
>
>>> It's a good approach to let fellow committers review such work before
>>> it gets committed to the codebase.
>> I agree in theory, but given the poor state of the codebase I feel that
>> requiring that every single change is delayed for 2/3 days or more to
>> let people review it is not manageable.
>
> This is how community projects work!
>
> If you want to introduce new features or important changes to the codebase, you will have to propose them and stand the discussion (and maybe delays
> of a few weeks if not months). It is the responsibility of the contributor to prove his solution being a good fit for the project beforehand.
>
> The quality of code you mentioned partly is a result of times when a few committers simply forced their changes into the codebase whether the
> community liked it or not.
>
>>
>> The approach I am following in practice is to apply my own judgement to
>> separate things that are safe and things that need to be discussed
>> beforehand.
>
> As committers we should act as positive examples on how good community work should be lived. New features, especially if they have an impact on the
> users, should always be discussed beforehand. And if they get accepted, it should also include a good documentation and migration guide for the users.
>
>
>>
>> I considered (maybe wrongly) that using <depends-on> in the “framework”
>> and “applications” components directories was safe because it did not
>> remove any feature.
>
> It *does* remove a feature from a users perspective. The component-load.xml will be gone and custom enhancements will not work ootb after the change.
>
>>
>>> This change will affect existing productive installations and should
>>> not be made without proper documentation and clear instructions for
>>> the user on how to migrate their installation to the new mechanism.
>>>
>>> To me it is not clear what we are gaining with this change. We are
>>> removing one tag which is used and stable for years and introduce
>>> another one which was not used before. Users are forced to migrate
>>> their installations if they had custom modifications.
>> I am confused about what you are talking about because I still don't see
>> in what has already been committed in ‘trunk’ what is “affecting
>> productive installations” because the “component-load.xml” feature is
>> still here and users can still place their existing “component-load.xml”
>> files and get the same behavior as before.
>
> See above. Users are driving serious business with the OFBiz platform and we should have this in mind when we are doing changes to the codebase.
>
> It's not just a technical change, it affects projects, needs migration testing etc. and therefore it should be discussed thoroughly if this is a
> good and needed change.
>
>>
>>> I did not look deeply into the changes yet but it looks strange that a
>>> component like "product" or "order" only depends on "humanres". In
>>> fact, they have more dependencies like "party". Given that
>>> "depends-on" really means what it says and has a real difference to
>>> the component-load.xml approach.
>> The dependency relation is transitive meaning:
>>
>> if (x depends on y) and (y depends on z) then (x depends on z).
>>
>> It is possible to be explicit about the "transitive" dependencies by
>> declaring them as direct dependencies when the fact that a direct
>> dependency is depending on another one is an implementation details
>> which might not hold in the future.
>>
>> For example: the Gradle plugin “groovy” depends on the Gradle plugin
>> “java” but there is little chance that the “groovy” plugin will not
>> depend on the “java” one in the future so it is safe to only declare a
>> dependency on the “groovy” plugin.
>>
>> The current dependency declarations in framework/applications is a
>> direct mapping of the order defined in the previous “component-load.xml”
>> file which need to be refined because that order lacked information
>> regarding the actual functional dependencies (which is the inherent
>> downside of using a total order for partially ordered things).
>
> The current implementation of "depends-on" does also lack information of functional dependencies because they are not clearly visible at teh place
> where they are defined.
>
> IMO it does not improve the transparency of the dependencies better than the "component-load" approach.
>
>
>>
>>> The component-load.xml mechanism clearly shows the loading order of
>>> the components which is an advantage over the cluttered information of
>>> the depends-on mechanism. You will have to analyze every
>>> ofbiz-component to see what's going on.
>> You are correct that “component-load.xml” shows the precise loading
>> order of components, however it lacks a precise definition of the actual
>> functional dependencies between components.
>>
>> You can derive one valid loading order from the set of actual functional
>> dependencies, however as stated above it is not possible to derive the
>> functional dependencies from a “component-load.xml” file.
>>
>> Currently we lack a mechanism to display the global dependency graph
>> which is important to for example to analyse why a component is loaded
>> before or after another one.  However this feature should be easy to
>> implement and could be a requirement before removing the
>> “component-load.xml” feature.
>>
>>> IMO these examples show that is in fact worth a discussion and should
>>> not be a lone decision of a single committer.
>>>
>>> I would like to see this being reverted and proposed for discussion
>>> and review before this is going to be introduced into the codebase.
>> I have no problem reverting things, however to be legitim your call for
>> revert should be backed by an actual proof that the “component-load.xml”
>> feature has been removed (which is not the case) or that the component
>> loading work has introduced a bug/regression.
>
> See my statements about community work above.
>
>>
>> So I encourage you to try to backport one of your production
>> “component-load.xml” on trunk and report a bug if necessary.
>
> Did you test how "depends-on" is working together with the "component-load" mechanism?
>
> It is not my responsibility to prove that it is not working, it is yours to prove that it works.
>
>
>>
>> Thanks.
>>
> Let me say that I really appreciate your work for the project, Mathieu.
>
> I'm simply trying to keep up good community work and feel responsible for the users of the project, hence my objections.
>
> Thanks,
>
> Michael
>
>
>
>
>

[Jacques Le Roux]

Hi All,

Have we a lazy consensus here?

Jacques

Le 10/12/2019 à 06:17, Jacques Le Roux a écrit :

> Hi Michael, Mathieu,
>
> Why not keeping both features and have a simple way (if it does not exist yet) to choose the one to use?
>
> BTW Michael,  you are certainly aware, you have a mail certificate issue.
>
> Thanks
>
> Jacques
>
> Le 09/12/2019 à 08:08, Michael Brohl a écrit :
>> Hi Mathieu,
>>
>> inline...
>>
>>>> It's a good approach to let fellow committers review such work before
>>>> it gets committed to the codebase.
>>> I agree in theory, but given the poor state of the codebase I feel that
>>> requiring that every single change is delayed for 2/3 days or more to
>>> let people review it is not manageable.
>>
>> This is how community projects work!
>>
>> If you want to introduce new features or important changes to the codebase, you will have to propose them and stand the discussion (and maybe
>> delays of a few weeks if not months). It is the responsibility of the contributor to prove his solution being a good fit for the project beforehand.
>>
>> The quality of code you mentioned partly is a result of times when a few committers simply forced their changes into the codebase whether the
>> community liked it or not.
>>
>>>
>>> The approach I am following in practice is to apply my own judgement to
>>> separate things that are safe and things that need to be discussed
>>> beforehand.
>>
>> As committers we should act as positive examples on how good community work should be lived. New features, especially if they have an impact on the
>> users, should always be discussed beforehand. And if they get accepted, it should also include a good documentation and migration guide for the users.
>>
>>
>>>
>>> I considered (maybe wrongly) that using <depends-on> in the “framework”
>>> and “applications” components directories was safe because it did not
>>> remove any feature.
>>
>> It *does* remove a feature from a users perspective. The component-load.xml will be gone and custom enhancements will not work ootb after the change.
>>
>>>
>>>> This change will affect existing productive installations and should
>>>> not be made without proper documentation and clear instructions for
>>>> the user on how to migrate their installation to the new mechanism.
>>>>
>>>> To me it is not clear what we are gaining with this change. We are
>>>> removing one tag which is used and stable for years and introduce
>>>> another one which was not used before. Users are forced to migrate
>>>> their installations if they had custom modifications.
>>> I am confused about what you are talking about because I still don't see
>>> in what has already been committed in ‘trunk’ what is “affecting
>>> productive installations” because the “component-load.xml” feature is
>>> still here and users can still place their existing “component-load.xml”
>>> files and get the same behavior as before.
>>
>> See above. Users are driving serious business with the OFBiz platform and we should have this in mind when we are doing changes to the codebase.
>>
>> It's not just a technical change, it affects projects, needs migration testing etc. and therefore it should be discussed thoroughly if this is a
>> good and needed change.
>>
>>>
>>>> I did not look deeply into the changes yet but it looks strange that a
>>>> component like "product" or "order" only depends on "humanres". In
>>>> fact, they have more dependencies like "party". Given that
>>>> "depends-on" really means what it says and has a real difference to
>>>> the component-load.xml approach.
>>> The dependency relation is transitive meaning:
>>>
>>> if (x depends on y) and (y depends on z) then (x depends on z).
>>>
>>> It is possible to be explicit about the "transitive" dependencies by
>>> declaring them as direct dependencies when the fact that a direct
>>> dependency is depending on another one is an implementation details
>>> which might not hold in the future.
>>>
>>> For example: the Gradle plugin “groovy” depends on the Gradle plugin
>>> “java” but there is little chance that the “groovy” plugin will not
>>> depend on the “java” one in the future so it is safe to only declare a
>>> dependency on the “groovy” plugin.
>>>
>>> The current dependency declarations in framework/applications is a
>>> direct mapping of the order defined in the previous “component-load.xml”
>>> file which need to be refined because that order lacked information
>>> regarding the actual functional dependencies (which is the inherent
>>> downside of using a total order for partially ordered things).
>>
>> The current implementation of "depends-on" does also lack information of functional dependencies because they are not clearly visible at teh place
>> where they are defined.
>>
>> IMO it does not improve the transparency of the dependencies better than the "component-load" approach.
>>
>>
>>>
>>>> The component-load.xml mechanism clearly shows the loading order of
>>>> the components which is an advantage over the cluttered information of
>>>> the depends-on mechanism. You will have to analyze every
>>>> ofbiz-component to see what's going on.
>>> You are correct that “component-load.xml” shows the precise loading
>>> order of components, however it lacks a precise definition of the actual
>>> functional dependencies between components.
>>>
>>> You can derive one valid loading order from the set of actual functional
>>> dependencies, however as stated above it is not possible to derive the
>>> functional dependencies from a “component-load.xml” file.
>>>
>>> Currently we lack a mechanism to display the global dependency graph
>>> which is important to for example to analyse why a component is loaded
>>> before or after another one.  However this feature should be easy to
>>> implement and could be a requirement before removing the
>>> “component-load.xml” feature.
>>>
>>>> IMO these examples show that is in fact worth a discussion and should
>>>> not be a lone decision of a single committer.
>>>>
>>>> I would like to see this being reverted and proposed for discussion
>>>> and review before this is going to be introduced into the codebase.
>>> I have no problem reverting things, however to be legitim your call for
>>> revert should be backed by an actual proof that the “component-load.xml”
>>> feature has been removed (which is not the case) or that the component
>>> loading work has introduced a bug/regression.
>>
>> See my statements about community work above.
>>
>>>
>>> So I encourage you to try to backport one of your production
>>> “component-load.xml” on trunk and report a bug if necessary.
>>
>> Did you test how "depends-on" is working together with the "component-load" mechanism?
>>
>> It is not my responsibility to prove that it is not working, it is yours to prove that it works.
>>
>>
>>>
>>> Thanks.
>>>
>> Let me say that I really appreciate your work for the project, Mathieu.
>>
>> I'm simply trying to keep up good community work and feel responsible for the users of the project, hence my objections.
>>
>> Thanks,
>>
>> Michael
>>
>>
>>
>>
>>
>

[Michael Brohl-3]

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.

If you would build a house together with others, noone would ever have
the idea to change things overnight without discussing it first.


Am 13.12.19 um 16:32 schrieb Jacques Le Roux:

> Hi All,
>
> Have we a lazy consensus here?
>
> Jacques
>
> Le 10/12/2019 à 06:17, Jacques Le Roux a écrit :
>> Hi Michael, Mathieu,
>>
>> Why not keeping both features and have a simple way (if it does not
>> exist yet) to choose the one to use?
>>
>> BTW Michael,  you are certainly aware, you have a mail certificate
>> issue.
>>
>> Thanks
>>
>> Jacques
>>
>> Le 09/12/2019 à 08:08, Michael Brohl a écrit :
>>> Hi Mathieu,
>>>
>>> inline...
>>>
>>>>> It's a good approach to let fellow committers review such work before
>>>>> it gets committed to the codebase.
>>>> I agree in theory, but given the poor state of the codebase I feel
>>>> that
>>>> requiring that every single change is delayed for 2/3 days or more to
>>>> let people review it is not manageable.
>>>
>>> This is how community projects work!
>>>
>>> If you want to introduce new features or important changes to the
>>> codebase, you will have to propose them and stand the discussion
>>> (and maybe delays of a few weeks if not months). It is the
>>> responsibility of the contributor to prove his solution being a good
>>> fit for the project beforehand.
>>>
>>> The quality of code you mentioned partly is a result of times when a
>>> few committers simply forced their changes into the codebase whether
>>> the community liked it or not.
>>>
>>>>
>>>> The approach I am following in practice is to apply my own
>>>> judgement to
>>>> separate things that are safe and things that need to be discussed
>>>> beforehand.
>>>
>>> As committers we should act as positive examples on how good
>>> community work should be lived. New features, especially if they
>>> have an impact on the users, should always be discussed beforehand.
>>> And if they get accepted, it should also include a good
>>> documentation and migration guide for the users.
>>>
>>>
>>>>
>>>> I considered (maybe wrongly) that using <depends-on> in the
>>>> “framework”
>>>> and “applications” components directories was safe because it did not
>>>> remove any feature.
>>>
>>> It *does* remove a feature from a users perspective. The
>>> component-load.xml will be gone and custom enhancements will not
>>> work ootb after the change.
>>>
>>>>
>>>>> This change will affect existing productive installations and should
>>>>> not be made without proper documentation and clear instructions for
>>>>> the user on how to migrate their installation to the new mechanism.
>>>>>
>>>>> To me it is not clear what we are gaining with this change. We are
>>>>> removing one tag which is used and stable for years and introduce
>>>>> another one which was not used before. Users are forced to migrate
>>>>> their installations if they had custom modifications.
>>>> I am confused about what you are talking about because I still
>>>> don't see
>>>> in what has already been committed in ‘trunk’ what is “affecting
>>>> productive installations” because the “component-load.xml” feature is
>>>> still here and users can still place their existing
>>>> “component-load.xml”
>>>> files and get the same behavior as before.
>>>
>>> See above. Users are driving serious business with the OFBiz
>>> platform and we should have this in mind when we are doing changes
>>> to the codebase.
>>>
>>> It's not just a technical change, it affects projects, needs
>>> migration testing etc. and therefore it should be discussed
>>> thoroughly if this is a good and needed change.
>>>
>>>>
>>>>> I did not look deeply into the changes yet but it looks strange
>>>>> that a
>>>>> component like "product" or "order" only depends on "humanres". In
>>>>> fact, they have more dependencies like "party". Given that
>>>>> "depends-on" really means what it says and has a real difference to
>>>>> the component-load.xml approach.
>>>> The dependency relation is transitive meaning:
>>>>
>>>> if (x depends on y) and (y depends on z) then (x depends on z).
>>>>
>>>> It is possible to be explicit about the "transitive" dependencies by
>>>> declaring them as direct dependencies when the fact that a direct
>>>> dependency is depending on another one is an implementation details
>>>> which might not hold in the future.
>>>>
>>>> For example: the Gradle plugin “groovy” depends on the Gradle plugin
>>>> “java” but there is little chance that the “groovy” plugin will not
>>>> depend on the “java” one in the future so it is safe to only declare a
>>>> dependency on the “groovy” plugin.
>>>>
>>>> The current dependency declarations in framework/applications is a
>>>> direct mapping of the order defined in the previous
>>>> “component-load.xml”
>>>> file which need to be refined because that order lacked information
>>>> regarding the actual functional dependencies (which is the inherent
>>>> downside of using a total order for partially ordered things).
>>>
>>> The current implementation of "depends-on" does also lack
>>> information of functional dependencies because they are not clearly
>>> visible at teh place where they are defined.
>>>
>>> IMO it does not improve the transparency of the dependencies better
>>> than the "component-load" approach.
>>>
>>>
>>>>
>>>>> The component-load.xml mechanism clearly shows the loading order of
>>>>> the components which is an advantage over the cluttered
>>>>> information of
>>>>> the depends-on mechanism. You will have to analyze every
>>>>> ofbiz-component to see what's going on.
>>>> You are correct that “component-load.xml” shows the precise loading
>>>> order of components, however it lacks a precise definition of the
>>>> actual
>>>> functional dependencies between components.
>>>>
>>>> You can derive one valid loading order from the set of actual
>>>> functional
>>>> dependencies, however as stated above it is not possible to derive the
>>>> functional dependencies from a “component-load.xml” file.
>>>>
>>>> Currently we lack a mechanism to display the global dependency graph
>>>> which is important to for example to analyse why a component is loaded
>>>> before or after another one.  However this feature should be easy to
>>>> implement and could be a requirement before removing the
>>>> “component-load.xml” feature.
>>>>
>>>>> IMO these examples show that is in fact worth a discussion and should
>>>>> not be a lone decision of a single committer.
>>>>>
>>>>> I would like to see this being reverted and proposed for discussion
>>>>> and review before this is going to be introduced into the codebase.
>>>> I have no problem reverting things, however to be legitim your call
>>>> for
>>>> revert should be backed by an actual proof that the
>>>> “component-load.xml”
>>>> feature has been removed (which is not the case) or that the component
>>>> loading work has introduced a bug/regression.
>>>
>>> See my statements about community work above.
>>>
>>>>
>>>> So I encourage you to try to backport one of your production
>>>> “component-load.xml” on trunk and report a bug if necessary.
>>>
>>> Did you test how "depends-on" is working together with the
>>> "component-load" mechanism?
>>>
>>> It is not my responsibility to prove that it is not working, it is
>>> yours to prove that it works.
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>> Let me say that I really appreciate your work for the project, Mathieu.
>>>
>>> I'm simply trying to keep up good community work and feel
>>> responsible for the users of the project, hence my objections.
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>

[Mathieu Lirzin]

Hello Michael,

Michael Brohl <[hidden email]> 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

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[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.

If not I would like to refocus the discussion on the next step which is
about the propositions of:

1. Removing “base/config/component-load.xml” and hard-code the
   ["framework", "themes", "applications", "plugins"] sequence with the
   new requirement that extensions must be done inside “plugins” as long
   as we don't have a location-independent extension mechanism [2].

2. Removing the “component-load.xml” feature which provides a mechanism
   to define an arbitrary order for a set of components inside a
   directory to bypass the “smart loading” derived from functional
   component dependency declarations. This removal is a pre-requisite to
   implement a location-independent extension mechanism [2].

Are there any objection regarding those 2 propositions ?

[1] https://github.com/apache/ofbiz-framework/commit/eeabe69813a1d9f42911dec70a912574046ef49b
[2] https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E

Mathieu Lirzin <[hidden email]> writes:

> Michael Brohl <[hidden email]> 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

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Michael Brohl-3]

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 <[hidden email]> writes:
>
>> Michael Brohl <[hidden email]> 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

[Mathieu Lirzin]

Hello Michael,

Michael Brohl <[hidden email]> 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

[Jacques Le Roux]

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 <[hidden email]> writes:
>>
>>> Michael Brohl <[hidden email]> 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
>

[Jacques Le Roux]

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 <[hidden email]> writes:
>>>
>>>> Michael Brohl <[hidden email]> 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
>>
>

[Samuel-2]

Hi all,


Quoting Jacques Le Roux (2019-12-18 12:39:56)
> 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).

feature forking is another discussion => agree with this! But I'd like
to finish this discussion about component-load.xml because I still want
to remove this file (I mean in framework, in plugins you can do whatever
you want)

>
> 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...

It is working with component-load.xml from the start! but not with
framework, applications components directories which is (from my point
of view) an implementation detail: you should not rely on which order
framework is loading its components!

It seems to me that you should write your code in plugins and actually
in plugins you can expect every components in framework to be loaded,
but maybe I'm wrong about how users use obfiz framework...

>
> 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

yes we are still waiting for your answer Michael ;) In my opinion we
cannot go ahead in this discussion without your answer, without your
need about component-load.xml: are you trying to avoid loading a
particular framework component? do you patch a framework component and
need another one to be loaded first to make your patch works? ...

> >
> > Michael does not answer this question but reiterate a question Mathieu did not answer yet: "is [this] tested working [together] with component-load.xm"

Condidering poor test coverage of obfiz this question seems to me
irrelevant! I will really appreciate to reject any patch proposal which
does not come with a test, but, if I'm correct, this not a practise in
ofbiz community.

As I've done the requested test manually and Mathieu has reverted the
commit I think we can left behind this question.

Samuel

> >
> > I believe these points must be answered before we get further in this discussion
> >
> > Jacques
> >

[Jacques Le Roux]

Hi Samuel, All,

Le 18/12/2019 à 14:00, Samuel Trégouët a écrit :

> 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...
> It is working with component-load.xml from the start! but not with
> framework, applications components directories which is (from my point
> of view) an implementation detail: you should not rely on which order
> framework is loading its components!

Yes, but so far that's an unavoidable fact. please refer to the wiki page I posted earlier (with a dependencies graph in). Anyway here it is:

https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies

There are several possibilities to avoid that, but none are free (as free beer), and that's an euphemism...


> It seems to me that you should write your code in plugins and actually
> in plugins you can expect every components in framework to be loaded,
> but maybe I'm wrong about how users use obfiz framework...

We must face reality (please refer to the dependencies  graph again) , as you know component-load.xml is not only used in plugins.


>
>> Le 18/12/2019 à 12:09, Jacques Le Roux a écrit :
>>> Mathieu asks Michael to provide  an "explanation regarding why it matters in production environments to be able to patch" component-load.xml files
> yes we are still waiting for your answer Michael ;) In my opinion we
> cannot go ahead in this discussion without your answer, without your
> need about component-load.xml: are you trying to avoid loading a
> particular framework component? do you patch a framework component and
> need another one to be loaded first to make your patch works? ...

That's an interesting point indeed. Have you your own framework component/s Michael ?

>
>>> Michael does not answer this question but reiterate a question Mathieu did not answer yet: "is [this] tested working [together] with component-load.xm"
> As I've done the requested test manually and Mathieu has reverted the
> commit I think we can left behind this question.
>
> Samuel
>
>>> I believe these points must be answered before we get further in this discussion
>>>
>>> Jacques

Thanks for this effort Samuel! Was it difficult?

Jacques