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

[Mathieu Lirzin]

Hello,

Here are two clarifications about removing the “component-load.xml”
feature.

Michael Brohl <[hidden email]> writes:

> Am 05.01.20 um 18:32 schrieb Mathieu Lirzin:
>
>> effectively optional (like the marketing example you brought) it should
>> eventually be moved in the official plugins if we actually want to
>> provides the capability for users to disable it. However users should
>
> Even it it would be a plugin, you still need a mechanism to
> enable/disable it by configuration.
>
> To my understanding, if we use depends-on exclusively for framework,
> applications and plugins, this would not be possible anymore.

It depends if you consider modifying the “ofbiz-component.xml” as
configuration or not. If yes there exists the “enabled” attribute of the
<ofbiz-component> element which provides a mechanism to disable a
component.

> Am 06.01.20 um 10:29 schrieb Samuel Trégouët:
>
>> 1. component-load.xml in plugin directory seems to be feature (nobody
>>     discuss this point)
>
> That *might* be a misunderstanding (if Mathieu agrees on this
> point). My understanding was that he first implemented and committed
> the change for framework and applications (on Nov. 25).
>
> From his mail in dev [1] and also the issue title of [2] I understand
> that the component-load mechanism should be removed *everywhere*
> afterwards. The dev mail would not make sense otherwise because
> already committed the work at the time of writing (two weeks before)
> and he announces to go on if noone objects.
>
> I apologize if I missed a point here, maybe Mathieu can clarify this?

Even if I advocate for superseding “plugins/component-load.xml” with
<depends-on>, I recognize it as a feature (documented briefly in the
README).

You are correct that in [1] I did not mention that feature and focus on
the removal of “framework/base/component-load.xml” which is another
potential user-space configuration mechanism.  I could have spoken about
the “plugins/component-load.xml” feature too but at that time I thought
it was less likely to matter than “framework/base/component-load.xml”
because of the immaturity of the plugins mechanism and the long term
existence of “framework/base/component-load.xml”.

Does it clarify things?

>> [1]: https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E
>> [2]: https://lists.apache.org/thread.html/7eab3d2ae3bbeadb184b02f75f7b2b86263532485e88ecba4d4dc780%40%3Cdev.ofbiz.apache.org%3E


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

[Mathieu Lirzin]

Hello Paul, Jacopo and Olivier,

Paul Foxworthy <[hidden email]> writes:

> Being clearer about it would be a good thing.  There is still the
> potential that a change that seems simple and straightforward to one
> contributor is disruptive to others. And if it truly is disruptive, we
> should collaborate on what comes next. Are the benefits worth the
> disruption? Should there be some sort of deprecation, phase-out or
> backwards compatibility option? I can't clearly define what "big" is,
> but I know it when I see it.

IMO “We Should collaborate” is wishful thinking, because in practice
what happens most of the time is that only one person is doing the work
that he/she is proposing and the rest is doing +1 or -1. When someone
objects it often just means more burden for the person doing the work
because the person objecting will just add extra requirements.

Don't get me wrong, I find that situation normal because nobody is doing
a better job than someone who is motivated about it. Moreover people
with “ideas” but which are not responsible for implementing those tend
to advocate less practicable ideas.

It is just that I don't think we should expect the community to work
collectively better than the norm by relying on collaboration to be able
to get things done.

Jacopo Cappellato <[hidden email]> writes:

> There will always be a tension between guaranteeing backward compatibility
> for the existing user base and the efforts to maintain our codebase,
> enhance/refactor/innovate it.
> Considering the peculiar nature of OFBiz, I don't think that trying to
> define the areas that are part of the "public API" and then guarantee
> backward compatibility only for them, will resolve this tension. In fact
> there may be cases in which the "public API" should change in a
> non-backward compatible way such as:
> * the cost of maintaining a backward compatible feature is too high for our
> community (or there is not enough interest in the active community in
> maintaining it)
> * the change is required to fix a flaw or a security vulnerability
> * some fundamental (and important to the community) architectural change
> may not be backward compatible
> * etc...

Specifying a public API does not mean necessarily preserving it. It just
mean knowing when a border is being crossed:

- The developer changing something that is part of that API
- The user using an undocumented mechanism that happen to be here.

> Apart from this, even the definition of "public API" for OFBiz is
> troublesome considering for example that potentially any OFBiz service can
> be used by "client" code and as a consequence in theory our community
> should never change the behavior (or remove) a service.

Ideally yes because the notion of services is about providing something
to others.  To reduce the compatibility cost it should be possible to
make “convenience” services that are only meant to be used locally by
other services, be implemented as a private/package level helper methods
instead of a service.

I don't have specific examples in mind but I am pretty sure that there
exist a lot of those.

> There are cases (like the one that triggered this conversation) that may
> involve some community discussion because it is difficult to figure out if
> the cost (in terms of pains for our users) is worth the gain (in terms of
> better/cleaner code): sometimes these discussions can be frustrating but if
> we all try to stay open (to the other point of view), positive, flexible,
> patient I am sure we will cope with them.

I agree that it is normal to spend some potentially long time discussing
the tradeoffs when considering a change that impact the public API
(whether it just adds a new feature or it breaks/deprecate existing
ones)

However knowing the boundaries between the public/private API is very
useful to understand each other and agree on the extent of those
tradeoffs.

For example in the current situation it happens that Michael is
considering “applications/component-load.xml” part of the implicit
public API¹ and as a consequence requires a community validation, a
deprecation period and a migration guides to be provided. When in the
same time I am considering it as an implementation detail that don't
need such extra work on my side.

Basically listening to each other in the context of an objection to a
change means putting all the burden on the framework developper which
either have to spend time convincing users that they should not use one
thing and migrate to another thing, or adding corner cases inside the
code to preverve the specific behavior expected by users.

Moreover even if the burden is all on the developer this still sucks
because it works only for users involved in the development (subscribed
to ML), but others will have to deal with their own unexpected breakage
without having the developer to help them.

Olivier Heintz <[hidden email]> writes:

> 4) implementation detail or core choice, often, it's depend of point
> of view you use On ERP development / implementation there are multiple
> type of people working on it with each one, specifics knowledge,
> usage, practice and point of view.  When someone says, it's a big
> change, start by trusting him and find out which process is affected
> to propose a solution; he doesn't want to block something, he wants to
> help you come up with a better solution that solves more cases.

Given that it is very easy to get a convincing argument by saying
“people might depend on …”, I am rather skeptic.

Even if I trust others for providing valuable inputs or proposing good
ideas, I am confident that if someone happen to rely on any mechanism in
production that is considered for removal/rewrite he/she will always
choose a solution that make the person proposing the change to do
whatever is necessary to not require them to do a migration work.

Again I am not saying that this is wrong, I am just saying that this
natural force should be balanced with something assessing that only a
subset of all mechanisms are subjects to such argument and using the
complement of that subset mean that users are on their own and they
should be prepared for breaking changes.

> 6) what is OFBiz,
>   - not only a public API ;-)
>   - not only a framework
>   - currently not a OOTB ERP  but I hope what, in future, there will contain some OOTB applications
> In my long term view Apache OFBiz could be like linux, a core/kernel as small as possible with multiple components (the plugins) and so with some
> distributions.
> So, clearly, for me it is not possible to define the boundary between what is public (with backward compatibility) and what is only implementation.
> Even on data model I can give some examples where not everyone will agree on what is in kernel and what is in components

I believe that any effort of modularizing the code base without relying
on a stable public API like moving plugins inside independent
repositories is doomed. I am personnally still not convince that seeking
for dozens of custom plugins is a good idea even with a stable public
API.

Regarding the core + plugins ideal, it is interesting that you brought
the linux kernel example because it is the perfect example of a
monolithic development process where every driver/module (plugin) that
seeks for backward compatibility must be maintained inside the main
repository because there is no guarantee on the interface between the
core and the plugins. A week ago, here is what Linus Torvalds was saying
to people considering developing a module for ZFS (a file system)
outside of the main repository [1].

I am curious about the data model example you have in mind?

[1] https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841

¹ The question about “plugins/component-load.xml” is different because
there is a consensus on the fact that is part of public API however I
have the impression that it is still in alpha state given that plugins
mechanism is relatively new.

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

[taher]

Hello Mathieu and all,

Thank you for this interesting and engaging thread. Before I make my
input, I would like to note that Apache OFBiz and its community from
my experience is welcoming of change and improvements. In my earlier
days in the project we went through massive changes to the system that
made tremendous differences including:

- Moving from ant to gradle
- introducing unit tests
- Redesigning the startup logic and possible flags
- Changing the distribution mechanism (remote dependencies instead of
inside the code base)
- Changing folder structures in components
- many others

While working on all the above, I never faced major obstacles. But the
reason that I did not is I always made a complete, well written
argument about what I'm trying to implement. I always ask for a pair
of eyes to look at my code and give me feedback, and I always engage
with the community. In my opinion, disagreements made me do some of
the best pieces of code because I learn and grow from other people's
input.

The boundary of a public API does not necessarily need to be agreed
upon RIGHT NOW!. I don't think the best way to move forward is to
enforce agreeing on what we should done before hand.

Instead of setting rules and boundaries on what should and should not
be done, I recommend instead collaborating on all work, one piece at a
time. As I said, I've worked on very large issues indeed and had no
problem working it with others and making it eventually to the code
base.

So whenever there is a disagreement or differing points of view, why
not start a new thread specific to that topic and work it out.
Everybody wants the best for the project, and communication is the key
to moving us forward IMHO.

My 2 cents

Cheers,
Taher Alkhateeb

On Sun, Jan 12, 2020 at 4:56 AM Mathieu Lirzin
<[hidden email]> wrote:

>
> Hello Paul, Jacopo and Olivier,
>
> Paul Foxworthy <[hidden email]> writes:
>
> > Being clearer about it would be a good thing.  There is still the
> > potential that a change that seems simple and straightforward to one
> > contributor is disruptive to others. And if it truly is disruptive, we
> > should collaborate on what comes next. Are the benefits worth the
> > disruption? Should there be some sort of deprecation, phase-out or
> > backwards compatibility option? I can't clearly define what "big" is,
> > but I know it when I see it.
>
> IMO “We Should collaborate” is wishful thinking, because in practice
> what happens most of the time is that only one person is doing the work
> that he/she is proposing and the rest is doing +1 or -1. When someone
> objects it often just means more burden for the person doing the work
> because the person objecting will just add extra requirements.
>
> Don't get me wrong, I find that situation normal because nobody is doing
> a better job than someone who is motivated about it. Moreover people
> with “ideas” but which are not responsible for implementing those tend
> to advocate less practicable ideas.
>
> It is just that I don't think we should expect the community to work
> collectively better than the norm by relying on collaboration to be able
> to get things done.
>
> Jacopo Cappellato <[hidden email]> writes:
>
> > There will always be a tension between guaranteeing backward compatibility
> > for the existing user base and the efforts to maintain our codebase,
> > enhance/refactor/innovate it.
> > Considering the peculiar nature of OFBiz, I don't think that trying to
> > define the areas that are part of the "public API" and then guarantee
> > backward compatibility only for them, will resolve this tension. In fact
> > there may be cases in which the "public API" should change in a
> > non-backward compatible way such as:
> > * the cost of maintaining a backward compatible feature is too high for our
> > community (or there is not enough interest in the active community in
> > maintaining it)
> > * the change is required to fix a flaw or a security vulnerability
> > * some fundamental (and important to the community) architectural change
> > may not be backward compatible
> > * etc...
>
> Specifying a public API does not mean necessarily preserving it. It just
> mean knowing when a border is being crossed:
>
> - The developer changing something that is part of that API
> - The user using an undocumented mechanism that happen to be here.
>
> > Apart from this, even the definition of "public API" for OFBiz is
> > troublesome considering for example that potentially any OFBiz service can
> > be used by "client" code and as a consequence in theory our community
> > should never change the behavior (or remove) a service.
>
> Ideally yes because the notion of services is about providing something
> to others.  To reduce the compatibility cost it should be possible to
> make “convenience” services that are only meant to be used locally by
> other services, be implemented as a private/package level helper methods
> instead of a service.
>
> I don't have specific examples in mind but I am pretty sure that there
> exist a lot of those.
>
> > There are cases (like the one that triggered this conversation) that may
> > involve some community discussion because it is difficult to figure out if
> > the cost (in terms of pains for our users) is worth the gain (in terms of
> > better/cleaner code): sometimes these discussions can be frustrating but if
> > we all try to stay open (to the other point of view), positive, flexible,
> > patient I am sure we will cope with them.
>
> I agree that it is normal to spend some potentially long time discussing
> the tradeoffs when considering a change that impact the public API
> (whether it just adds a new feature or it breaks/deprecate existing
> ones)
>
> However knowing the boundaries between the public/private API is very
> useful to understand each other and agree on the extent of those
> tradeoffs.
>
> For example in the current situation it happens that Michael is
> considering “applications/component-load.xml” part of the implicit
> public API¹ and as a consequence requires a community validation, a
> deprecation period and a migration guides to be provided. When in the
> same time I am considering it as an implementation detail that don't
> need such extra work on my side.
>
> Basically listening to each other in the context of an objection to a
> change means putting all the burden on the framework developper which
> either have to spend time convincing users that they should not use one
> thing and migrate to another thing, or adding corner cases inside the
> code to preverve the specific behavior expected by users.
>
> Moreover even if the burden is all on the developer this still sucks
> because it works only for users involved in the development (subscribed
> to ML), but others will have to deal with their own unexpected breakage
> without having the developer to help them.
>
> Olivier Heintz <[hidden email]> writes:
>
> > 4) implementation detail or core choice, often, it's depend of point
> > of view you use On ERP development / implementation there are multiple
> > type of people working on it with each one, specifics knowledge,
> > usage, practice and point of view.  When someone says, it's a big
> > change, start by trusting him and find out which process is affected
> > to propose a solution; he doesn't want to block something, he wants to
> > help you come up with a better solution that solves more cases.
>
> Given that it is very easy to get a convincing argument by saying
> “people might depend on …”, I am rather skeptic.
>
> Even if I trust others for providing valuable inputs or proposing good
> ideas, I am confident that if someone happen to rely on any mechanism in
> production that is considered for removal/rewrite he/she will always
> choose a solution that make the person proposing the change to do
> whatever is necessary to not require them to do a migration work.
>
> Again I am not saying that this is wrong, I am just saying that this
> natural force should be balanced with something assessing that only a
> subset of all mechanisms are subjects to such argument and using the
> complement of that subset mean that users are on their own and they
> should be prepared for breaking changes.
>
> > 6) what is OFBiz,
> >   - not only a public API ;-)
> >   - not only a framework
> >   - currently not a OOTB ERP  but I hope what, in future, there will contain some OOTB applications
> > In my long term view Apache OFBiz could be like linux, a core/kernel as small as possible with multiple components (the plugins) and so with some
> > distributions.
> > So, clearly, for me it is not possible to define the boundary between what is public (with backward compatibility) and what is only implementation.
> > Even on data model I can give some examples where not everyone will agree on what is in kernel and what is in components
>
> I believe that any effort of modularizing the code base without relying
> on a stable public API like moving plugins inside independent
> repositories is doomed. I am personnally still not convince that seeking
> for dozens of custom plugins is a good idea even with a stable public
> API.
>
> Regarding the core + plugins ideal, it is interesting that you brought
> the linux kernel example because it is the perfect example of a
> monolithic development process where every driver/module (plugin) that
> seeks for backward compatibility must be maintained inside the main
> repository because there is no guarantee on the interface between the
> core and the plugins. A week ago, here is what Linus Torvalds was saying
> to people considering developing a module for ZFS (a file system)
> outside of the main repository [1].
>
> I am curious about the data model example you have in mind?
>
> [1] https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841
>
> ¹ The question about “plugins/component-load.xml” is different because
> there is a consensus on the fact that is part of public API however I
> have the impression that it is still in alpha state given that plugins
> mechanism is relatively new.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Jacques Le Roux]

Great Message Taher!

Jacques

Le 20/01/2020 à 11:50, Taher Alkhateeb a écrit :

> Hello Mathieu and all,
>
> Thank you for this interesting and engaging thread. Before I make my
> input, I would like to note that Apache OFBiz and its community from
> my experience is welcoming of change and improvements. In my earlier
> days in the project we went through massive changes to the system that
> made tremendous differences including:
>
> - Moving from ant to gradle
> - introducing unit tests
> - Redesigning the startup logic and possible flags
> - Changing the distribution mechanism (remote dependencies instead of
> inside the code base)
> - Changing folder structures in components
> - many others
>
> While working on all the above, I never faced major obstacles. But the
> reason that I did not is I always made a complete, well written
> argument about what I'm trying to implement. I always ask for a pair
> of eyes to look at my code and give me feedback, and I always engage
> with the community. In my opinion, disagreements made me do some of
> the best pieces of code because I learn and grow from other people's
> input.
>
> The boundary of a public API does not necessarily need to be agreed
> upon RIGHT NOW!. I don't think the best way to move forward is to
> enforce agreeing on what we should done before hand.
>
> Instead of setting rules and boundaries on what should and should not
> be done, I recommend instead collaborating on all work, one piece at a
> time. As I said, I've worked on very large issues indeed and had no
> problem working it with others and making it eventually to the code
> base.
>
> So whenever there is a disagreement or differing points of view, why
> not start a new thread specific to that topic and work it out.
> Everybody wants the best for the project, and communication is the key
> to moving us forward IMHO.
>
> My 2 cents
>
> Cheers,
> Taher Alkhateeb
>
> On Sun, Jan 12, 2020 at 4:56 AM Mathieu Lirzin
> <[hidden email]> wrote:
>> Hello Paul, Jacopo and Olivier,
>>
>> Paul Foxworthy <[hidden email]> writes:
>>
>>> Being clearer about it would be a good thing.  There is still the
>>> potential that a change that seems simple and straightforward to one
>>> contributor is disruptive to others. And if it truly is disruptive, we
>>> should collaborate on what comes next. Are the benefits worth the
>>> disruption? Should there be some sort of deprecation, phase-out or
>>> backwards compatibility option? I can't clearly define what "big" is,
>>> but I know it when I see it.
>> IMO “We Should collaborate” is wishful thinking, because in practice
>> what happens most of the time is that only one person is doing the work
>> that he/she is proposing and the rest is doing +1 or -1. When someone
>> objects it often just means more burden for the person doing the work
>> because the person objecting will just add extra requirements.
>>
>> Don't get me wrong, I find that situation normal because nobody is doing
>> a better job than someone who is motivated about it. Moreover people
>> with “ideas” but which are not responsible for implementing those tend
>> to advocate less practicable ideas.
>>
>> It is just that I don't think we should expect the community to work
>> collectively better than the norm by relying on collaboration to be able
>> to get things done.
>>
>> Jacopo Cappellato <[hidden email]> writes:
>>
>>> There will always be a tension between guaranteeing backward compatibility
>>> for the existing user base and the efforts to maintain our codebase,
>>> enhance/refactor/innovate it.
>>> Considering the peculiar nature of OFBiz, I don't think that trying to
>>> define the areas that are part of the "public API" and then guarantee
>>> backward compatibility only for them, will resolve this tension. In fact
>>> there may be cases in which the "public API" should change in a
>>> non-backward compatible way such as:
>>> * the cost of maintaining a backward compatible feature is too high for our
>>> community (or there is not enough interest in the active community in
>>> maintaining it)
>>> * the change is required to fix a flaw or a security vulnerability
>>> * some fundamental (and important to the community) architectural change
>>> may not be backward compatible
>>> * etc...
>> Specifying a public API does not mean necessarily preserving it. It just
>> mean knowing when a border is being crossed:
>>
>> - The developer changing something that is part of that API
>> - The user using an undocumented mechanism that happen to be here.
>>
>>> Apart from this, even the definition of "public API" for OFBiz is
>>> troublesome considering for example that potentially any OFBiz service can
>>> be used by "client" code and as a consequence in theory our community
>>> should never change the behavior (or remove) a service.
>> Ideally yes because the notion of services is about providing something
>> to others.  To reduce the compatibility cost it should be possible to
>> make “convenience” services that are only meant to be used locally by
>> other services, be implemented as a private/package level helper methods
>> instead of a service.
>>
>> I don't have specific examples in mind but I am pretty sure that there
>> exist a lot of those.
>>
>>> There are cases (like the one that triggered this conversation) that may
>>> involve some community discussion because it is difficult to figure out if
>>> the cost (in terms of pains for our users) is worth the gain (in terms of
>>> better/cleaner code): sometimes these discussions can be frustrating but if
>>> we all try to stay open (to the other point of view), positive, flexible,
>>> patient I am sure we will cope with them.
>> I agree that it is normal to spend some potentially long time discussing
>> the tradeoffs when considering a change that impact the public API
>> (whether it just adds a new feature or it breaks/deprecate existing
>> ones)
>>
>> However knowing the boundaries between the public/private API is very
>> useful to understand each other and agree on the extent of those
>> tradeoffs.
>>
>> For example in the current situation it happens that Michael is
>> considering “applications/component-load.xml” part of the implicit
>> public API¹ and as a consequence requires a community validation, a
>> deprecation period and a migration guides to be provided. When in the
>> same time I am considering it as an implementation detail that don't
>> need such extra work on my side.
>>
>> Basically listening to each other in the context of an objection to a
>> change means putting all the burden on the framework developper which
>> either have to spend time convincing users that they should not use one
>> thing and migrate to another thing, or adding corner cases inside the
>> code to preverve the specific behavior expected by users.
>>
>> Moreover even if the burden is all on the developer this still sucks
>> because it works only for users involved in the development (subscribed
>> to ML), but others will have to deal with their own unexpected breakage
>> without having the developer to help them.
>>
>> Olivier Heintz <[hidden email]> writes:
>>
>>> 4) implementation detail or core choice, often, it's depend of point
>>> of view you use On ERP development / implementation there are multiple
>>> type of people working on it with each one, specifics knowledge,
>>> usage, practice and point of view.  When someone says, it's a big
>>> change, start by trusting him and find out which process is affected
>>> to propose a solution; he doesn't want to block something, he wants to
>>> help you come up with a better solution that solves more cases.
>> Given that it is very easy to get a convincing argument by saying
>> “people might depend on …”, I am rather skeptic.
>>
>> Even if I trust others for providing valuable inputs or proposing good
>> ideas, I am confident that if someone happen to rely on any mechanism in
>> production that is considered for removal/rewrite he/she will always
>> choose a solution that make the person proposing the change to do
>> whatever is necessary to not require them to do a migration work.
>>
>> Again I am not saying that this is wrong, I am just saying that this
>> natural force should be balanced with something assessing that only a
>> subset of all mechanisms are subjects to such argument and using the
>> complement of that subset mean that users are on their own and they
>> should be prepared for breaking changes.
>>
>>> 6) what is OFBiz,
>>>    - not only a public API ;-)
>>>    - not only a framework
>>>    - currently not a OOTB ERP  but I hope what, in future, there will contain some OOTB applications
>>> In my long term view Apache OFBiz could be like linux, a core/kernel as small as possible with multiple components (the plugins) and so with some
>>> distributions.
>>> So, clearly, for me it is not possible to define the boundary between what is public (with backward compatibility) and what is only implementation.
>>> Even on data model I can give some examples where not everyone will agree on what is in kernel and what is in components
>> I believe that any effort of modularizing the code base without relying
>> on a stable public API like moving plugins inside independent
>> repositories is doomed. I am personnally still not convince that seeking
>> for dozens of custom plugins is a good idea even with a stable public
>> API.
>>
>> Regarding the core + plugins ideal, it is interesting that you brought
>> the linux kernel example because it is the perfect example of a
>> monolithic development process where every driver/module (plugin) that
>> seeks for backward compatibility must be maintained inside the main
>> repository because there is no guarantee on the interface between the
>> core and the plugins. A week ago, here is what Linus Torvalds was saying
>> to people considering developing a module for ZFS (a file system)
>> outside of the main repository [1].
>>
>> I am curious about the data model example you have in mind?
>>
>> [1] https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841
>>
>> ¹ The question about “plugins/component-load.xml” is different because
>> there is a consensus on the fact that is part of public API however I
>> have the impression that it is still in alpha state given that plugins
>> mechanism is relatively new.
>>
>> --
>> Mathieu Lirzin
>> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Mathieu Lirzin]

Hello,

Taher Alkhateeb <[hidden email]> writes:

> While working on all the above, I never faced major obstacles. But the
> reason that I did not is I always made a complete, well written
> argument about what I'm trying to implement. I always ask for a pair
> of eyes to look at my code and give me feedback, and I always engage
> with the community. In my opinion, disagreements made me do some of
> the best pieces of code because I learn and grow from other people's
> input.

That sounds a lot like a polite way to suggest that I did not engage
properly with the community. I have done my best to get people involved
while acknowledging the need to move relatively fast which IMO is
justified by the abyssal technical debt of OFBiz.

> The boundary of a public API does not necessarily need to be agreed
> upon RIGHT NOW!. I don't think the best way to move forward is to
> enforce agreeing on what we should done before hand.
>
> Instead of setting rules and boundaries on what should and should not
> be done, I recommend instead collaborating on all work, one piece at a
> time. As I said, I've worked on very large issues indeed and had no
> problem working it with others and making it eventually to the code
> base.
>
> So whenever there is a disagreement or differing points of view, why
> not start a new thread specific to that topic and work it out.
> Everybody wants the best for the project, and communication is the key
> to moving us forward IMHO.

I agree that communication is important as long as it enables people to
move forward, currently we are blocked.  If you look at the initial
discussion, you will see that this is precisely a deadlock in a *thread
specific* conversation between Michael and me that lead to this general
question.

This specific discussion is simply unsolvable because everybody is
basing their arguments on undocumented assumptions regarding what needs
to be preserved, what needs to be superseded, how things are supposed to
be done, etc.  This is basically a sterile “you broke my business
specific extension” vs “I want to improve the framework” debate where
both perspective can be seen as legitimate but are fundamentally
incompatible with each other in practice.

To recap the discussion, it appears that most people that have responded
to my call for defining/documenting what is part of OFBiz public API
feel this would be an unnecessary and counter-productive action and that
case by case discussions can be a more valuable substitute.

As a consequence I think we can close the subject now.

Thanks to everyone who took some of their time to participate.

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

[Jacques Le Roux]

Le 21/01/2020 à 00:36, Mathieu Lirzin a écrit :

> Hello,
>
> Taher Alkhateeb <[hidden email]> writes:
>
>> While working on all the above, I never faced major obstacles. But the
>> reason that I did not is I always made a complete, well written
>> argument about what I'm trying to implement. I always ask for a pair
>> of eyes to look at my code and give me feedback, and I always engage
>> with the community. In my opinion, disagreements made me do some of
>> the best pieces of code because I learn and grow from other people's
>> input.
> That sounds a lot like a polite way to suggest that I did not engage
> properly with the community. I have done my best to get people involved
> while acknowledging the need to move relatively fast which IMO is
> justified by the abyssal technical debt of OFBiz.
>
>> The boundary of a public API does not necessarily need to be agreed
>> upon RIGHT NOW!. I don't think the best way to move forward is to
>> enforce agreeing on what we should done before hand.
>>
>> Instead of setting rules and boundaries on what should and should not
>> be done, I recommend instead collaborating on all work, one piece at a
>> time. As I said, I've worked on very large issues indeed and had no
>> problem working it with others and making it eventually to the code
>> base.
>>
>> So whenever there is a disagreement or differing points of view, why
>> not start a new thread specific to that topic and work it out.
>> Everybody wants the best for the project, and communication is the key
>> to moving us forward IMHO.
> I agree that communication is important as long as it enables people to
> move forward, currently we are blocked.  If you look at the initial
> discussion, you will see that this is precisely a deadlock in a *thread
> specific* conversation between Michael and me that lead to this general
> question.
>
> This specific discussion is simply unsolvable because everybody is
> basing their arguments on undocumented assumptions regarding what needs
> to be preserved, what needs to be superseded, how things are supposed to
> be done, etc.  This is basically a sterile “you broke my business
> specific extension” vs “I want to improve the framework” debate where
> both perspective can be seen as legitimate but are fundamentally
> incompatible with each other in practice.
>
> To recap the discussion, it appears that most people that have responded
> to my call for defining/documenting what is part of OFBiz public API
> feel this would be an unnecessary and counter-productive action and that
> case by case discussions can be a more valuable substitute.
>
> As a consequence I think we can close the subject now.
>
> Thanks to everyone who took some of their time to participate.
>

Hi Mathieu,

Sorry I disagree, I for one would very like to have what you expressed at https://s.apache.org/5gryr in OFBiz in future

We can agree to disagree with Michael, and have it in trunk. As I said already, it would let several years for users (like Michael) to adjust.

Of course for that we need a vote and Michael not to veto this change on trunk with solid arguments.

Else, seeing yours and Samuel's recent framework efforts compared to the rest of the community, I fear the future of OFBiz is not bright. Apart if we
consider the UI as the most important, which I don't...

I'm ready to engage a vote if you agree with me

Thanks

Jacques

[Pierre Smits-3]

Hi all,

The mission of the project is, in line with the ASF, to provide software
for the greater good and offering (potential) adopters a choice. In the
projects case this is done through providing the OFBiz works (each and all
products, as well as the supporting tooling for enabling contributors like
JIRA, Github services, etc.)

The project has since its inception as a TLP made it clear, with the above
in mind, that the the project is not responsible for the choices a
(potential) adopter has made, nor that it will be held responsible for the
future choices of an adopter.
This means, when talking about the code of the main OFBiz product, the
project does not care whether an adopter (being it either an enterprise
having OFBiz implemented, or a service integrator offering services and/or
solutions for payment or not) uses, enhances or diminishes the OFBiz
functionalities in upstream activities.

The project has also made clear in communications to every kind of
community member and adopter, that for use, enhancement or diminishment of
OFBiz functionalities in his environment of development and service
delivery the adopter should always start from releases and not from the
volatile trunk repositories.
Unfortunately, there have been (and are) several prominent members of the
OFBiz community that have made assertions that it was quite ok for adopters
to start with the code in the trunk branch of the repo for their own
develop and/or implementation.
When these community members propagate this start-with-trunk paradigm in
their upstream needs-and-wants model, they tend to shoot in their own foot.
But instead of acknowledging that they took a wrong turn and remediate that
situation, they elect to bring their problem down to the OFBiz project and
demand that the other contributor removes this undesirable change from the
OFBiz code base, in order to keep the upstream deviation minimally
disrupted.

Given what Mathieu has brought forward regarding the 'depends-on'
enhancement of the OFBiz functionality, it is clear that it strengthens and
enhances understandings regarding the OFBiz product and its intricacies
(where the code is the documentation).

When looking at the process undertaken by Mathieu, he was working within
his mandate as a community member with the commit-privilege to commit the
changes to the trunk branch of the repo (as per ticket OFBIZ-11296, commit
 eeabe69813a1d9f42911dec70a912574046ef49b). Moreover, he was also working
along and in-line with precedents established by other community members
before he became a privileged contributor.

The discussion that later developed was a good thing, but with precedents
as they are it is unfortunate that the commit was later reverted.
Unfortunate, not because the discussion developed but because the commit
did not 'break the code'. Precedents have shown that questionable commits
did not lead to reversal of these commits.

If, and when, all understand the rules of engagement of the OFBiz project,
and act accordingly, there would never by such a (heated) discussion as
this one, or the ones leading up to this (whether started and followed
through in JIRA tickets, or on any of the mailing lists). Apparently many
of the community members (including those with privileges) do not
understand what these are or these provide to ambiguity which leads to
deviations when contributing.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

[Jacques Le Roux]

Thanks Pierre,

I second that, I would not write it better!

Jacques

Le 21/01/2020 à 15:56, Pierre Smits a écrit :

> Hi all,
>
> The mission of the project is, in line with the ASF, to provide software
> for the greater good and offering (potential) adopters a choice. In the
> projects case this is done through providing the OFBiz works (each and all
> products, as well as the supporting tooling for enabling contributors like
> JIRA, Github services, etc.)
>
> The project has since its inception as a TLP made it clear, with the above
> in mind, that the the project is not responsible for the choices a
> (potential) adopter has made, nor that it will be held responsible for the
> future choices of an adopter.
> This means, when talking about the code of the main OFBiz product, the
> project does not care whether an adopter (being it either an enterprise
> having OFBiz implemented, or a service integrator offering services and/or
> solutions for payment or not) uses, enhances or diminishes the OFBiz
> functionalities in upstream activities.
>
> The project has also made clear in communications to every kind of
> community member and adopter, that for use, enhancement or diminishment of
> OFBiz functionalities in his environment of development and service
> delivery the adopter should always start from releases and not from the
> volatile trunk repositories.
> Unfortunately, there have been (and are) several prominent members of the
> OFBiz community that have made assertions that it was quite ok for adopters
> to start with the code in the trunk branch of the repo for their own
> develop and/or implementation.
> When these community members propagate this start-with-trunk paradigm in
> their upstream needs-and-wants model, they tend to shoot in their own foot.
> But instead of acknowledging that they took a wrong turn and remediate that
> situation, they elect to bring their problem down to the OFBiz project and
> demand that the other contributor removes this undesirable change from the
> OFBiz code base, in order to keep the upstream deviation minimally
> disrupted.
>
> Given what Mathieu has brought forward regarding the 'depends-on'
> enhancement of the OFBiz functionality, it is clear that it strengthens and
> enhances understandings regarding the OFBiz product and its intricacies
> (where the code is the documentation).
>
> When looking at the process undertaken by Mathieu, he was working within
> his mandate as a community member with the commit-privilege to commit the
> changes to the trunk branch of the repo (as per ticket OFBIZ-11296, commit
>   eeabe69813a1d9f42911dec70a912574046ef49b). Moreover, he was also working
> along and in-line with precedents established by other community members
> before he became a privileged contributor.
>
> The discussion that later developed was a good thing, but with precedents
> as they are it is unfortunate that the commit was later reverted.
> Unfortunate, not because the discussion developed but because the commit
> did not 'break the code'. Precedents have shown that questionable commits
> did not lead to reversal of these commits.
>
> If, and when, all understand the rules of engagement of the OFBiz project,
> and act accordingly, there would never by such a (heated) discussion as
> this one, or the ones leading up to this (whether started and followed
> through in JIRA tickets, or on any of the mailing lists). Apparently many
> of the community members (including those with privileges) do not
> understand what these are or these provide to ambiguity which leads to
> deviations when contributing.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer

[Michael Brohl-3]

HI Piere,

inline...


Am 21.01.20 um 15:56 schrieb Pierre Smits:
> Hi all,
>
> The mission of the project is, in line with the ASF, to provide software
> for the greater good and offering (potential) adopters a choice. In the
> projects case this is done through providing the OFBiz works (each and all
> products, as well as the supporting tooling for enabling contributors like
> JIRA, Github services, etc.)
Agreed and in no way questioned in the preceding discussions.
>
> The project has since its inception as a TLP made it clear, with the above
> in mind, that the the project is not responsible for the choices a
> (potential) adopter has made, nor that it will be held responsible for the
> future choices of an adopter.

Of course we are not held responsible in a legal sense. But we (should)
feel responsibility towards the users of the project and maintain it in
a way which is in good balance between the user base needs and the
contributions made to improve it.

> This means, when talking about the code of the main OFBiz product, the
> project does not care whether an adopter (being it either an enterprise
> having OFBiz implemented, or a service integrator offering services and/or
> solutions for payment or not) uses, enhances or diminishes the OFBiz
> functionalities in upstream activities.

Where do I find this anywhere in the statutes of the project?

I strongly disagree with this statement. If we propagate that we don't
care about the users and change the codebase, functionality and
mechanisms without thinking about backwards compatibility, breaking
existing projects and even don't support users with the documentation of
a migration path, we will damage the projects' reputation.

This is not a playground project, it is used in serious businesses and
we should have this in mind when changing things.

This is my main concern with the approach leading to the preceding
discussion.

>
> The project has also made clear in communications to every kind of
> community member and adopter, that for use, enhancement or diminishment of
> OFBiz functionalities in his environment of development and service
> delivery the adopter should always start from releases and not from the
> volatile trunk repositories.
> Unfortunately, there have been (and are) several prominent members of the
> OFBiz community that have made assertions that it was quite ok for adopters
> to start with the code in the trunk branch of the repo for their own
> develop and/or implementation.

Can you please point us to the source of these claims?

> When these community members propagate this start-with-trunk paradigm in
> their upstream needs-and-wants model, they tend to shoot in their own foot.
> But instead of acknowledging that they took a wrong turn and remediate that
> situation, they elect to bring their problem down to the OFBiz project and
> demand that the other contributor removes this undesirable change from the
> OFBiz code base, in order to keep the upstream deviation minimally
> disrupted.

This seems to be very speculative to me. Where does the information for
this claim come from?

The trunk is the source for the next stable branch and every change made
there will sooner or later be in a next release and will have effects on
users who will use it.

As a responsible developer, changes made to the codebase, especially if
they are made to support a future change/improvement/refactoring, should
be well planned, discussion, proved if they are really wanted/needed etc.

Another problem is that trunk receives a mix of functionality
enhancements and improvements for the business part and also core
improvements which might need a long time to be implemented (an example
might be the initiative to make the framework container independent).

If we want to have shorter release cycles to bring the functionality
updates to the users, this is in conflict with the improvements which
needs more time to be implemented and thorougly tested. This is the
reason why I would prefer to do these implementations in a feature
branch which will be held up-to-date with trunk and allows experimental
implementations without breaking anything. This is the classical and
logical way when maintaining a product.

If you would see the project as a software development company which
sells a product, this company would never start long-lasting
developments in the base branch for the next release.

Release management and a clear roadmap would help, maybe a dicussion for
another thread.

>
> Given what Mathieu has brought forward regarding the 'depends-on'
> enhancement of the OFBiz functionality, it is clear that it strengthens and
> enhances understandings regarding the OFBiz product and its intricacies
> (where the code is the documentation).

In this case, there seem to be plans in the minds of contributors which
lead to the discussed changes. These plans are neither documented nor
discussed in depth so that it is possible to make decisions. This is my
main concern.

I also gave several arguments why it breaks existing
functionality/configuration options when it is introduced in full (which
means also being introduced in applications and plugins).

I'm fine with the introduction in framework, even if I don't see why it
should be regarded as a big improvement. It will manage the dependencies
of 4 component folders in framework which will not change and have a
clear loading order.

In general, I definelety appreciate these initiatives but mainly
question the process/approach to introduce them. We already have
unfinished code/functionality in the project which is the result of this
approach. I simply want to avoid this.

>
> When looking at the process undertaken by Mathieu, he was working within
> his mandate as a community member with the commit-privilege to commit the
> changes to the trunk branch of the repo (as per ticket OFBIZ-11296, commit
>   eeabe69813a1d9f42911dec70a912574046ef49b). Moreover, he was also working
> along and in-line with precedents established by other community members
> before he became a privileged contributor.
>
> The discussion that later developed was a good thing, but with precedents
> as they are it is unfortunate that the commit was later reverted.
> Unfortunate, not because the discussion developed but because the commit
> did not 'break the code'. Precedents have shown that questionable commits
> did not lead to reversal of these commits.

It did not break the code but break the functionality which was present
with the component-load mechanism.

I think also made clear that I do not object a commit for the framework
part (excluding applications).

>
> If, and when, all understand the rules of engagement of the OFBiz project,
> and act accordingly, there would never by such a (heated) discussion as
> this one, or the ones leading up to this (whether started and followed
> through in JIRA tickets, or on any of the mailing lists). Apparently many
> of the community members (including those with privileges) do not
> understand what these are or these provide to ambiguity which leads to
> deviations when contributing.

Strong words and not even near to reality in my view.

Discussions being made to find the optimal approach/solution for a
problem are the core principal of community projects and they are needed
as we can see in many examples. And they always lead to better solutions
as if a single person would do them alone. A principle which is also
true for works withing teams of a company.

These discussions might be unconfortable for someone and make
developments slower, but I'm sure that they will be valuable and lead to
better results.

What I really miss is more people and especially committers to engage in
these discussions because I think they should be important to more than
a handfull of community members.

Thanks,

Michael


>
> Best regards,
>
> Pierre Smits
>

[Jacques Le Roux]

Hi All,

Since it's impossible to have both features (ie “base/config/component-load.xml” and <depends-on> present) and we don't reach a consensus I'll start a
vote about it.

Thanks

Jacques

Le 08/12/2019 à 02:34, Mathieu Lirzin a écrit :

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

[Jacques Le Roux]

Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :
> Hi All,
>
> Since it's impossible to have both features (ie “base/config/component-load.xml” and <depends-on> present) and we don't reach a consensus I'll start
> a vote about it.
>
> Thanks
>
> Jacques

Before I start a vote, here is a last try to get a consensus. Michael in his last email, answering to Pierre, made clear that he would not oppose to
<<Removing “base/config/component-load.xml”>>. His concern is more for application and plugins component-load.xml.

Could we not reach a consensus with this option? Mathieu, Samuel?

Then we could discuss more about details for application and plugins component-load.xml...

Jacques

[Michael Brohl-3]

Hi Jacques,

yes, my objection is targeted to the removal of the component-load.xml
mechanism for applications and plugins.

I don't think it will be a problem to remove it from
framework/base/config/ and hard code the four existing components
framework, themes, applications and plugins.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.01.20 um 08:03 schrieb Jacques Le Roux:

> Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :
>> Hi All,
>>
>> Since it's impossible to have both features (ie
>> “base/config/component-load.xml” and <depends-on> present) and we
>> don't reach a consensus I'll start a vote about it.
>>
>> Thanks
>>
>> Jacques
>
> Before I start a vote, here is a last try to get a consensus. Michael
> in his last email, answering to Pierre, made clear that he would not
> oppose to <<Removing “base/config/component-load.xml”>>. His concern
> is more for application and plugins component-load.xml.
>
> Could we not reach a consensus with this option? Mathieu, Samuel?
>
> Then we could discuss more about details for application and plugins
> component-load.xml...
>
> Jacques
>

[Jacques Le Roux]

Hi Mathieu, Samuel,

You were the most visible proponents of this. After 5 days w/o exchanges should we consider the idea is abandoned or should we start a vote?

Without answers I'll consider the idea abandoned, which is a pity IMO.

Thanks

Jacques

Le 24/01/2020 à 14:12, Michael Brohl a écrit :

> Hi Jacques,
>
> yes, my objection is targeted to the removal of the component-load.xml mechanism for applications and plugins.
>
> I don't think it will be a problem to remove it from framework/base/config/ and hard code the four existing components framework, themes,
> applications and plugins.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 24.01.20 um 08:03 schrieb Jacques Le Roux:
>> Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :
>>> Hi All,
>>>
>>> Since it's impossible to have both features (ie “base/config/component-load.xml” and <depends-on> present) and we don't reach a consensus I'll
>>> start a vote about it.
>>>
>>> Thanks
>>>
>>> Jacques
>>
>> Before I start a vote, here is a last try to get a consensus. Michael in his last email, answering to Pierre, made clear that he would not oppose
>> to <<Removing “base/config/component-load.xml”>>. His concern is more for application and plugins component-load.xml.
>>
>> Could we not reach a consensus with this option? Mathieu, Samuel?
>>
>> Then we could discuss more about details for application and plugins component-load.xml...
>>
>> Jacques
>>
>

[James Yong-2]

Added my comments on the technical aspects of the proposal at
https://issues.apache.org/jira/browse/OFBIZ-11296

On 2020/01/29 08:26:00, Jacques Le Roux <[hidden email]> wrote:

> Hi Mathieu, Samuel,
>
> You were the most visible proponents of this. After 5 days w/o exchanges should we consider the idea is abandoned or should we start a vote?
>
> Without answers I'll consider the idea abandoned, which is a pity IMO.
>
> Thanks
>
> Jacques
>
> Le 24/01/2020 à 14:12, Michael Brohl a écrit :
> > Hi Jacques,
> >
> > yes, my objection is targeted to the removal of the component-load.xml mechanism for applications and plugins.
> >
> > I don't think it will be a problem to remove it from framework/base/config/ and hard code the four existing components framework, themes,
> > applications and plugins.
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 24.01.20 um 08:03 schrieb Jacques Le Roux:
> >> Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :
> >>> Hi All,
> >>>
> >>> Since it's impossible to have both features (ie “base/config/component-load.xml” and <depends-on> present) and we don't reach a consensus I'll
> >>> start a vote about it.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>
> >> Before I start a vote, here is a last try to get a consensus. Michael in his last email, answering to Pierre, made clear that he would not oppose
> >> to <<Removing “base/config/component-load.xml”>>. His concern is more for application and plugins component-load.xml.
> >>
> >> Could we not reach a consensus with this option? Mathieu, Samuel?
> >>
> >> Then we could discuss more about details for application and plugins component-load.xml...
> >>
> >> Jacques
> >>
> >
>

[Jacques Le Roux]

Thanks James,

Maybe better to continue there indeed, less confusion, just focused on what's important.

Jacques

Le 29/01/2020 à 16:52, James Yong a écrit :

> Added my comments on the technical aspects of the proposal at
> https://issues.apache.org/jira/browse/OFBIZ-11296
>
> On 2020/01/29 08:26:00, Jacques Le Roux <[hidden email]> wrote:
>> Hi Mathieu, Samuel,
>>
>> You were the most visible proponents of this. After 5 days w/o exchanges should we consider the idea is abandoned or should we start a vote?
>>
>> Without answers I'll consider the idea abandoned, which is a pity IMO.
>>
>> Thanks
>>
>> Jacques
>>
>> Le 24/01/2020 à 14:12, Michael Brohl a écrit :
>>> Hi Jacques,
>>>
>>> yes, my objection is targeted to the removal of the component-load.xml mechanism for applications and plugins.
>>>
>>> I don't think it will be a problem to remove it from framework/base/config/ and hard code the four existing components framework, themes,
>>> applications and plugins.
>>>
>>> Thanks,
>>>
>>> Michael Brohl
>>>
>>> ecomify GmbH - www.ecomify.de
>>>
>>>
>>> Am 24.01.20 um 08:03 schrieb Jacques Le Roux:
>>>> Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :
>>>>> Hi All,
>>>>>
>>>>> Since it's impossible to have both features (ie “base/config/component-load.xml” and <depends-on> present) and we don't reach a consensus I'll
>>>>> start a vote about it.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>> Before I start a vote, here is a last try to get a consensus. Michael in his last email, answering to Pierre, made clear that he would not oppose
>>>> to <<Removing “base/config/component-load.xml”>>. His concern is more for application and plugins component-load.xml.
>>>>
>>>> Could we not reach a consensus with this option? Mathieu, Samuel?
>>>>
>>>> Then we could discuss more about details for application and plugins component-load.xml...
>>>>
>>>> Jacques
>>>>

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux <[hidden email]> writes:

> You were the most visible proponents of this. After 5 days w/o
> exchanges should we consider the idea is abandoned or should we start
> a vote?
>
> Without answers I'll consider the idea abandoned, which is a pity IMO.

The idea is not abandonned yet, it is just that I need to take some time
off to accept that my strategy consisting in trying to bring important
changes within OFBiz might actually be quixotic.

After re-reading [1] I am not sure to understand how a vote can help
resolving this issue because any -1 for code modification is considered
a veto (if it is “accompanied by a technical justification”).  So unless
the question that we vote on corresponds to Michael minimal
requirements, it will not enable us to move forward.

Am I overlooking something?

What question have you in mind for the vote?

Thanks for trying to make things move forward.

[1] https://www.apache.org/foundation/voting.html#Veto

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

[Jacques Le Roux]

Hi Mathieu

Le 29/01/2020 à 22:26, Mathieu Lirzin a écrit :

> Hello Jacques,
>
> Jacques Le Roux <[hidden email]> writes:
>
>> You were the most visible proponents of this. After 5 days w/o
>> exchanges should we consider the idea is abandoned or should we start
>> a vote?
>>
>> Without answers I'll consider the idea abandoned, which is a pity IMO.
> The idea is not abandonned yet, it is just that I need to take some time
> off to accept that my strategy consisting in trying to bring important
> changes within OFBiz might actually be quixotic.

Quixotic a new word for me :)


> After re-reading [1] I am not sure to understand how a vote can help
> resolving this issue because any -1 for code modification is considered
> a veto (if it is “accompanied by a technical justification”).  So unless
> the question that we vote on corresponds to Michael minimal
> requirements, it will not enable us to move forward.
>
> Am I overlooking something?
>
> What question have you in mind for the vote?

The idea is to vote about removing component-load.xml from the framework, as Michael agreed on, but let them in applications and plugins. Is that OK
with your plan?


> Thanks for trying to make things move forward.

You are welcome, all efforts to improve OFBiz are heading in the right direction for me.


> [1] https://www.apache.org/foundation/voting.html#Veto
>
Jacques

[Mathieu Lirzin]

Jacques Le Roux <[hidden email]> writes:

>> What question have you in mind for the vote?
>
> The idea is to vote about removing component-load.xml from the
> framework, as Michael agreed on, but let them in applications and
> plugins. Is that OK with your plan?

Not really but that is better than nothing.

Should the vote question include the fact that “component-load.xml”
feature will be deprecated in the next release and will be removed after
one release cycle?

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

[Jacques Le Roux]

Le 30/01/2020 à 17:51, Mathieu Lirzin a écrit :

> Jacques Le Roux <[hidden email]> writes:
>
>>> What question have you in mind for the vote?
>> The idea is to vote about removing component-load.xml from the
>> framework, as Michael agreed on, but let them in applications and
>> plugins. Is that OK with your plan?
> Not really but that is better than nothing.
>
> Should the vote question include the fact that “component-load.xml”
> feature will be deprecated in the next release and will be removed after
> one release cycle?

Yes, that's kind of what I think about.

We are blocking this improvement because of an external use of the feature. This external use should be adapted to use the replacing mechanism. That
needs a deprecation process.

In this context, I though see 2 different things:

 1. Remove component-load.xml from framework as it's not an issue for the external use. No deprecation process needed.
 2. Remove component-load.xml from applications and plugins. As it's an issue for the external use the deprecation process is needed.

Those should be clearly separated.

Jacques

[Michael Brohl-3]

Hi Jacques,

inline...


Am 31.01.20 um 10:06 schrieb Jacques Le Roux:

>
> Yes, that's kind of what I think about.
>
> We are blocking this improvement because of an external use of the
> feature. This external use should be adapted to use the replacing
> mechanism. That needs a deprecation process.
>
> In this context, I though see 2 different things:
>
> 1. Remove component-load.xml from framework as it's not an issue for
> the external use. No deprecation process needed.

Agreed.


> 2. Remove component-load.xml from applications and plugins. As it's an
> issue for the external use the deprecation process is needed.

This will need thorough discussion of all the pros and cons *before* we
take action on this. I feel this needs more discussion and awareness of
other community members and users.

A summary of the pros and cons would help making it easier for others to
decide.

And, most important, the big plan behind this should be laid out so that
we have a chance to understand why this would be important.


>
> Those should be clearly separated.

Agreed.


>
> Jacques
>
>
Thanks for the moderation of this topic,

Michael