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

[Jacques Le Roux]

Hi Michael

Le 31/01/2020 à 11:15, Michael Brohl a écrit :

> Hi Jacques,
>
> inline...
>
> Am 31.01.20 um 10:06 schrieb Jacques Le Roux:
>
>> 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.
>
> Michael

We have already 2 sources for that

The reasons it's planned: https://s.apache.org/7e590

We could continue the discussion in this thread or at https://issues.apache.org/jira/browse/OFBIZ-11296

https://issues.apache.org/jira/browse/OFBIZ-11161 is also related

Maybe better to create a new thread?

HTH

Jacques

[Michael Brohl-3]

Hi Jacques,

inline...

Am 31.01.20 um 13:15 schrieb Jacques Le Roux:

> Hi Michael
>
> Le 31/01/2020 à 11:15, Michael Brohl a écrit :
>> Hi Jacques,
>>
>> inline...
>>
>> Am 31.01.20 um 10:06 schrieb Jacques Le Roux:
>>
>>> 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.
>>
>> Michael
>
> We have already 2 sources for that
>
> The reasons it's planned: https://s.apache.org/7e590
>
> We could continue the discussion in this thread or at
> https://issues.apache.org/jira/browse/OFBIZ-11296

This issue shows exactly the same pattern in the process like the
component-load approach. The Jira was created and *on the same day* the
first patches were committed without further discussion within the Jira.
The Jiras contains a link to a discussion with the statement "this has
been discusses on Development mailing list".

In fact, the thread also started on the same day in dev but has not many
reactions and in no way any decision to go in that direction. This is by
no means the correct way to introduce fundamental changes to the project.

This is a huge and complex topic, not only on a technical level. This
needs a real concept to give everyone the chance to really understand
which consequences these changes will have. There are always pros and
cons for every solution and I am pretty sure that the consequences
cannot be overseen by single contributors and without the exchange
between a significant amount of experienced OFBiz contributors.

I'm also pretty sure that, if the community decides to go that way after
a thorough exchange of arguments and real life practical experience, the
implementation will be a long-running project itself. This cannot be
undertaken on the trunk but will need a feature branch, which has to be
discussed when the time is right.

As much as I appreciate the initiative to move things forward I am also
strictly against the approach and process to put fundamental changes
into the codebase without through conceptual work and planning.


>
> https://issues.apache.org/jira/browse/OFBIZ-11161 is also related
>
> Maybe better to create a new thread?

We already have a thread for it, started on 22. August 2019. I would
very much appreciate if experienced users/developers would join this
discussion (which I have missed being on vacation at the time and,
having not much response, did not get my attention until now).


>
> HTH
>
> Jacques
>
Thanks,

Michael

[Jacques Le Roux]

Le 31/01/2020 à 15:04, Michael Brohl a écrit :
> Hi Jacques,
>
> inline...
>>
>> Maybe better to create a new thread?
>
> We already have a thread for it, started on 22. August 2019. I would very much appreciate if experienced users/developers would join this discussion
> (which I have missed being on vacation at the time and, having not much response, did not get my attention until now).

Could you please send a link to this thread or its title? I could not find it easily

Thanks

Jacques

[Michael Brohl-3]

Pleas see my previous email, the discussion thread link is there
(citating your own statement...)

Thanks,

Michael


Am 31.01.20 um 15:34 schrieb Jacques Le Roux:

> Le 31/01/2020 à 15:04, Michael Brohl a écrit :
>> Hi Jacques,
>>
>> inline...
>>>
>>> Maybe better to create a new thread?
>>
>> We already have a thread for it, started on 22. August 2019. I would
>> very much appreciate if experienced users/developers would join this
>> discussion (which I have missed being on vacation at the time and,
>> having not much response, did not get my attention until now).
>
> Could you please send a link to this thread or its title? I could not
> find it easily
>
> Thanks
>
> Jacques
>

[Jacques Le Roux]

Le 31/01/2020 à 11:15, Michael Brohl a écrit :
> Hi Jacques,
>
> inline...
>
>> 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.
>
Since you are against this change could you write the cons?

Jacques

[Jacques Le Roux]

This is exactly the reason why I would prefer to start a new. Things get confusing.

I'd finally prefer a new clean thread with the pro and cons for everybody to make an opinion which would allow to start a vote, since a consensus
can't be reached

I hope Mathieu could write the pro...

If we agree on that one of us can star the new clean thread and we can focus on the underneath of the problem w/o digressing

I know it's another effort for you and Mathieu, but I can't see a better way to avoid drowning less concerned people in details.

We really need to focus, thanks

Jacques

Le 31/01/2020 à 16:11, Michael Brohl a écrit :

> Pleas see my previous email, the discussion thread link is there (citating your own statement...)
>
> Thanks,
>
> Michael
>
>
> Am 31.01.20 um 15:34 schrieb Jacques Le Roux:
>> Le 31/01/2020 à 15:04, Michael Brohl a écrit :
>>> Hi Jacques,
>>>
>>> inline...
>>>>
>>>> Maybe better to create a new thread?
>>>
>>> We already have a thread for it, started on 22. August 2019. I would very much appreciate if experienced users/developers would join this
>>> discussion (which I have missed being on vacation at the time and, having not much response, did not get my attention until now).
>>
>> Could you please send a link to this thread or its title? I could not find it easily
>>
>> Thanks
>>
>> Jacques
>>
>

[Pierre Smits-3]

I suggest a WIP page in our confluence, e.g having a table with 2 columns,
so that any contributor can bring his own pro and/or con forward. This way
everybody can have an overview of what's on the table. And that could be
the basis for discussions.

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


On Fri, Jan 31, 2020 at 4:48 PM Jacques Le Roux <
[hidden email]> wrote:

> This is exactly the reason why I would prefer to start a new. Things get
> confusing.
>
> I'd finally prefer a new clean thread with the pro and cons for everybody
> to make an opinion which would allow to start a vote, since a consensus
> can't be reached
>
> I hope Mathieu could write the pro...
>
> If we agree on that one of us can star the new clean thread and we can
> focus on the underneath of the problem w/o digressing
>
> I know it's another effort for you and Mathieu, but I can't see a better
> way to avoid drowning less concerned people in details.
>
> We really need to focus, thanks
>
> Jacques
>
> Le 31/01/2020 à 16:11, Michael Brohl a écrit :
> > Pleas see my previous email, the discussion thread link is there
> (citating your own statement...)
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 31.01.20 um 15:34 schrieb Jacques Le Roux:
> >> Le 31/01/2020 à 15:04, Michael Brohl a écrit :
> >>> Hi Jacques,
> >>>
> >>> inline...
> >>>>
> >>>> Maybe better to create a new thread?
> >>>
> >>> We already have a thread for it, started on 22. August 2019. I would
> very much appreciate if experienced users/developers would join this
> >>> discussion (which I have missed being on vacation at the time and,
> having not much response, did not get my attention until now).
> >>
> >> Could you please send a link to this thread or its title? I could not
> find it easily
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >
>

[Jacques Le Roux]

That sounds like a good idea, James (Yong) already gave some pro argument and have questions in OFBIZ-11296

Jacques

Le 31/01/2020 à 16:51, Pierre Smits a écrit :

> I suggest a WIP page in our confluence, e.g having a table with 2 columns,
> so that any contributor can bring his own pro and/or con forward. This way
> everybody can have an overview of what's on the table. And that could be
> the basis for discussions.
>
> 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
>
>
> On Fri, Jan 31, 2020 at 4:48 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> This is exactly the reason why I would prefer to start a new. Things get
>> confusing.
>>
>> I'd finally prefer a new clean thread with the pro and cons for everybody
>> to make an opinion which would allow to start a vote, since a consensus
>> can't be reached
>>
>> I hope Mathieu could write the pro...
>>
>> If we agree on that one of us can star the new clean thread and we can
>> focus on the underneath of the problem w/o digressing
>>
>> I know it's another effort for you and Mathieu, but I can't see a better
>> way to avoid drowning less concerned people in details.
>>
>> We really need to focus, thanks
>>
>> Jacques
>>
>> Le 31/01/2020 à 16:11, Michael Brohl a écrit :
>>> Pleas see my previous email, the discussion thread link is there
>> (citating your own statement...)
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> Am 31.01.20 um 15:34 schrieb Jacques Le Roux:
>>>> Le 31/01/2020 à 15:04, Michael Brohl a écrit :
>>>>> Hi Jacques,
>>>>>
>>>>> inline...
>>>>>> Maybe better to create a new thread?
>>>>> We already have a thread for it, started on 22. August 2019. I would
>> very much appreciate if experienced users/developers would join this
>>>>> discussion (which I have missed being on vacation at the time and,
>> having not much response, did not get my attention until now).
>>>> Could you please send a link to this thread or its title? I could not
>> find it easily
>>>> Thanks
>>>>
>>>> Jacques
>>>>

[Gil Portenseigne]

I agree with Jacques, i tried several times to participate in the
discussion but i am confused about the situation.

About this situation, Michael, we get your point about the process of
discuss things before modifying not trivial code and I do agree with
that. But there can always be mistakes.

I'm pretty sure that Mathieu's intentions are well guided, and reading
this last email about the bad process of Mathieu contribution make me
feel bad for him.

I hope we can get past this, now that it is clear, and work together
about the technical aspects, which will make it easier for people to
intervene.

Thanks and best regards.

Gil



On Fri, Jan 31, 2020 at 04:47:41PM +0100, Jacques Le Roux wrote:

> This is exactly the reason why I would prefer to start a new. Things get confusing.
>
> I'd finally prefer a new clean thread with the pro and cons for everybody to
> make an opinion which would allow to start a vote, since a consensus can't
> be reached
>
> I hope Mathieu could write the pro...
>
> If we agree on that one of us can star the new clean thread and we can focus on the underneath of the problem w/o digressing
>
> I know it's another effort for you and Mathieu, but I can't see a better way to avoid drowning less concerned people in details.
>
> We really need to focus, thanks
>
> Jacques
>
> Le 31/01/2020 à 16:11, Michael Brohl a écrit :
> > Pleas see my previous email, the discussion thread link is there (citating your own statement...)
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 31.01.20 um 15:34 schrieb Jacques Le Roux:
> > > Le 31/01/2020 à 15:04, Michael Brohl a écrit :
> > > > Hi Jacques,
> > > >
> > > > inline...
> > > > >
> > > > > Maybe better to create a new thread?
> > > >
> > > > We already have a thread for it, started on 22. August 2019. I
> > > > would very much appreciate if experienced users/developers would
> > > > join this discussion (which I have missed being on vacation at
> > > > the time and, having not much response, did not get my attention
> > > > until now).
> > >
> > > Could you please send a link to this thread or its title? I could not find it easily
> > >
> > > Thanks
> > >
> > > Jacques
> > >
> >

[Mathieu Lirzin]

Hello,

Michael Brohl <[hidden email]> writes:

> Am 31.01.20 um 13:15 schrieb Jacques Le Roux:
>>
>> We could continue the discussion in this thread or at
>> https://issues.apache.org/jira/browse/OFBIZ-11296
>
>
> This issue shows exactly the same pattern in the process like the
> component-load approach. The Jira was created and *on the same day*
> the first patches were committed without further discussion within the
> Jira. The Jiras contains a link to a discussion with the statement
> "this has been discusses on Development mailing list".
>
> In fact, the thread also started on the same day in dev but has not
> many reactions and in no way any decision to go in that
> direction. This is by no means the correct way to introduce
> fundamental changes to the project.

This description is dishonest, I have always opened discussions on this
mailing-list and waited for feedback when considering a *big/breaking
change*. I have only moved fast when I considered that what I was
working on was an implementation detail and that the improvement was
obvious.

The actual issue is not that I did not follow the rules. The fact that I
ended up opening/closing a JIRA the same day I commit things that I
consider trivial was precisely to conform to the policy of “every change
needs to have a JIRA associated” which is bureaucratic non-sense.

The actual issue is that in the case of
“{framework,applications}/component-load.xml” we disagreed on the
trivial aspect of this change.  This disagreement is an expected thing
because nobody in this community can tell the difference between an
*implementation detail* and a *breaking change* because we don't have
(and don't want) a public API. This simply means that every code change
is a breaking change and that it should follow a slow process of review
to let evaluate the trade-offs between potential downstream breakage
(that we might not be aware of) and the actual benefits of the proposed
change.

> I'm also pretty sure that, if the community decides to go that way
> after a thorough exchange of arguments and real life practical
> experience, the implementation will be a long-running project
> itself. This cannot be undertaken on the trunk but will need a feature
> branch, which has to be discussed when the time is right.
>
> As much as I appreciate the initiative to move things forward I am
> also strictly against the approach and process to put fundamental
> changes into the codebase without through conceptual work and
> planning.

I am glad that you appreciate the initiative, but as far as I am
concerned I am certainly not enjoying my time in this community anymore.

>> https://issues.apache.org/jira/browse/OFBIZ-11161 is also related
>>
>> Maybe better to create a new thread?
>
> We already have a thread for it, started on 22. August 2019. I would
> very much appreciate if experienced users/developers would join this
> discussion (which I have missed being on vacation at the time and,
> having not much response, did not get my attention until now).

Basically you are acknowledging that nobody cares deeply about the idea
I proposed in previous thread (which is probably true) but at the same
time you are suggesting me to write a lengthy design/architectural
document that will rephrase what as already been said in that thread.

Sorry but no, I will not write such document, I have already explained
multiple times the design principles leading to the proposal of enabling
the distribution of OFBiz inside a Jar:

- Extensible dependency management is better than having to define a
  arbitrary global ordering

- Location independent loading/configuration mechanism is the only sane
  way to provide true extensibility.

- Adopting the stable mechanism provided by the Java platform that we
  already depend on is better than implementing our own specific
  mechanism

If people are not convinced by the benefits of this vision which imply
deprecating the “component-load.xml” mechanism and use “depends-on”
instead (which I did not introduced in the first place) then providing a
precise design/implementation plan will not help moving forward, it will
just lead to more time waste on my side.

I don't see the point of continuing this unproductive discussion neither
to proceed with a formal vote regarding the deprecation of
“component-load.xml”, because whatever the result I have lost my faith
in the capability of this community to succeed at handling the technical
challenges that will enable OFBiz to stay relevant in the future.

But this is fine.



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

[Michael Brohl-3]

Hi Mathieu,

I'm not sure if we understand each other correctly and maybe talk at
cross-puposes.

Hope you are open to read my comments inline...


Am 05.02.20 um 15:34 schrieb Mathieu Lirzin:

> Hello,
>
> Michael Brohl <[hidden email]> writes:
>
>> Am 31.01.20 um 13:15 schrieb Jacques Le Roux:
>>> We could continue the discussion in this thread or at
>>> https://issues.apache.org/jira/browse/OFBIZ-11296
>>
>> This issue shows exactly the same pattern in the process like the
>> component-load approach. The Jira was created and *on the same day*
>> the first patches were committed without further discussion within the
>> Jira. The Jiras contains a link to a discussion with the statement
>> "this has been discusses on Development mailing list".
>>
>> In fact, the thread also started on the same day in dev but has not
>> many reactions and in no way any decision to go in that
>> direction. This is by no means the correct way to introduce
>> fundamental changes to the project.
> This description is dishonest, I have always opened discussions on this
> mailing-list and waited for feedback when considering a *big/breaking
> change*. I have only moved fast when I considered that what I was
> working on was an implementation detail and that the improvement was
> obvious.

My latest emails were not adressed at the depends-on topic but the
changes proposed in [1]. See below also.

>
> The actual issue is not that I did not follow the rules. The fact that I
> ended up opening/closing a JIRA the same day I commit things that I
> consider trivial was precisely to conform to the policy of “every change
> needs to have a JIRA associated” which is bureaucratic non-sense.

I think it helps to keep track of the many issues we have to work on.

A good example is my own fault to not create a Jira for [3]: I fixed a
bug but forgot to backport.

If I had created a Jira, other might have spotted it and reacted or I
may have thought about backporting myself. It was sheer luck that I
stumbled upon it again.

>> As much as I appreciate the initiative to move things forward I am
>> also strictly against the approach and process to put fundamental
>> changes into the codebase without through conceptual work and
>> planning.
> I am glad that you appreciate the initiative, but as far as I am
> concerned I am certainly not enjoying my time in this community anymore.

For which I feel truly sorry and I apologize if I caused frustration and
did not find the right words to express my concerns in a more motivating
way.

>>> https://issues.apache.org/jira/browse/OFBIZ-11161 is also related
>>>
>>> Maybe better to create a new thread?
>> We already have a thread for it, started on 22. August 2019. I would
>> very much appreciate if experienced users/developers would join this
>> discussion (which I have missed being on vacation at the time and,
>> having not much response, did not get my attention until now).
> Basically you are acknowledging that nobody cares deeply about the idea
> I proposed in previous thread (which is probably true) but at the same

I did not say that nobody cares, I said that the thread does not get
many responses. The reasons can be manifold.

The reason why *I* have not responded is that I was on vacation and had
an immense workload of projects until the end of the year afterwards. I
was more or less off as you can see at my engagement in the dev list
after June.

Others may have had same issues. Sometimes a topic needs patience or
reminders for the community to pick up.

I care a lot for this topic, which is why I expressed my wish to the
community to join the discussion on several occasions. We simply have
different perspectives, which is good IMO. Together with more
perspectives from others, we will be able to build a clearer picture of
the vision and an actionable plan to reach its realization.

And I really think that a more detailed roadmap will help to engage more
people in the collaboration (which would be more fun also).


> time you are suggesting me to write a lengthy design/architectural
> document that will rephrase what as already been said in that thread.

I have suggested to write down and discuss important details and the
pros/cons of different approaches and ideas. IMO it's the only way to
engage the community in actionable work items and collaboration. It does
not necessarily mean that it needs lengthy documents. A simple Wiki page
would do for a start.

> Sorry but no, I will not write such document, I have already explained
> multiple times the design principles leading to the proposal of enabling
> the distribution of OFBiz inside a Jar:
>
> - Extensible dependency management is better than having to define a
>    arbitrary global ordering
>
> - Location independent loading/configuration mechanism is the only sane
>    way to provide true extensibility.
>
> - Adopting the stable mechanism provided by the Java platform that we
>    already depend on is better than implementing our own specific
>    mechanism
>
> If people are not convinced by the benefits of this vision which imply
> deprecating the “component-load.xml” mechanism and use “depends-on”
> instead (which I did not introduced in the first place) then providing a
> precise design/implementation plan will not help moving forward, it will
> just lead to more time waste on my side.

I think depends-on is a point we already have discussed and this was not
my topic in the latest emails. My proposal to write up a concept is
adressed to the "big picture" you have described in [1], which contains
your statement:

"Here is a *big* change that I am considering for OFBiz to fixes those
issues by leveraging the Java platform which already provides everything
that we need to fix those issues: ..."

I was talking about this big change and the plan behind it. In the
initial discussion you gave a brief vision, which should be worked out
by the community to move forward. A vision is far from a concept the
community can decide on, which is my main point I expressed earlier.

[2] is the Jira with first changes and commits regarding the big
picture, which is why I intervened to hold on and talk about the concept
before changing things in *trunk*.

> I don't see the point of continuing this unproductive discussion neither
> to proceed with a formal vote regarding the deprecation of
> “component-load.xml”, because whatever the result I have lost my faith
> in the capability of this community to succeed at handling the technical
> challenges that will enable OFBiz to stay relevant in the future.
>
> But this is fine.

As I've sorted out the "depends-on" topic as the reason for the wish for
a concept/plan: do you also think that a discussion about the *big
change* is unproductive and is not necessary?

How do you do conceptual work with clients or colleagues? I believe
there is some kind of written documentation and clear decision points
involved at least for non trivial features/changes.

I sincerely hope that we can sort out the resentments and find a way to
collaborate on the challenges that lay ahead.

Best regards,

Michael


[1] https://s.apache.org/7e590

[2] https://issues.apache.org/jira/browse/OFBIZ-11161

[3]
https://lists.apache.org/thread.html/re7d18081eea709568ad6b1076dcd7464fe750107e222dada0b4994a2%40%3Cdev.ofbiz.apache.org%3E

[taher]

Hello Folks,

I can sense frustration from Mathieu regarding getting things moving
forward. I would just like to note that it's really not _that_ bad!
You've already gotten a lot of commits rolling into the code base
(which is fantastic) and you didn't get objections on most of them. In
fact many commits that you made were just fine, including things you
did to the core components and gradle scripts and whatnot.

So I want to encourage you to trust that things would work themselves
out, and there is no need to be frustrated. Take a deep breath and
just consider more of a long-term initiative than a short term one.
Doing the jar architecture is not the only thing that can be improved.
There is a whole heap of areas in the framework that can be improved.
For example REST (which you worked on partially if I'm not mistaken).

Disagreements are usually a positive rather than a negative one,
because it allows us all to learn something new by looking at things
from different points of view. All in all,  I am appreciative of your
efforts and hope that you don't drop the ball.

Cheers,

Taher Alkhateeb

On Wed, Feb 5, 2020 at 8:29 PM Michael Brohl <[hidden email]> wrote:

>
> Hi Mathieu,
>
> I'm not sure if we understand each other correctly and maybe talk at
> cross-puposes.
>
> Hope you are open to read my comments inline...
>
>
> Am 05.02.20 um 15:34 schrieb Mathieu Lirzin:
> > Hello,
> >
> > Michael Brohl <[hidden email]> writes:
> >
> >> Am 31.01.20 um 13:15 schrieb Jacques Le Roux:
> >>> We could continue the discussion in this thread or at
> >>> https://issues.apache.org/jira/browse/OFBIZ-11296
> >>
> >> This issue shows exactly the same pattern in the process like the
> >> component-load approach. The Jira was created and *on the same day*
> >> the first patches were committed without further discussion within the
> >> Jira. The Jiras contains a link to a discussion with the statement
> >> "this has been discusses on Development mailing list".
> >>
> >> In fact, the thread also started on the same day in dev but has not
> >> many reactions and in no way any decision to go in that
> >> direction. This is by no means the correct way to introduce
> >> fundamental changes to the project.
> > This description is dishonest, I have always opened discussions on this
> > mailing-list and waited for feedback when considering a *big/breaking
> > change*. I have only moved fast when I considered that what I was
> > working on was an implementation detail and that the improvement was
> > obvious.
>
> My latest emails were not adressed at the depends-on topic but the
> changes proposed in [1]. See below also.
>
> >
> > The actual issue is not that I did not follow the rules. The fact that I
> > ended up opening/closing a JIRA the same day I commit things that I
> > consider trivial was precisely to conform to the policy of “every change
> > needs to have a JIRA associated” which is bureaucratic non-sense.
>
> I think it helps to keep track of the many issues we have to work on.
>
> A good example is my own fault to not create a Jira for [3]: I fixed a
> bug but forgot to backport.
>
> If I had created a Jira, other might have spotted it and reacted or I
> may have thought about backporting myself. It was sheer luck that I
> stumbled upon it again.
>
> >> As much as I appreciate the initiative to move things forward I am
> >> also strictly against the approach and process to put fundamental
> >> changes into the codebase without through conceptual work and
> >> planning.
> > I am glad that you appreciate the initiative, but as far as I am
> > concerned I am certainly not enjoying my time in this community anymore.
>
> For which I feel truly sorry and I apologize if I caused frustration and
> did not find the right words to express my concerns in a more motivating
> way.
>
> >>> https://issues.apache.org/jira/browse/OFBIZ-11161 is also related
> >>>
> >>> Maybe better to create a new thread?
> >> We already have a thread for it, started on 22. August 2019. I would
> >> very much appreciate if experienced users/developers would join this
> >> discussion (which I have missed being on vacation at the time and,
> >> having not much response, did not get my attention until now).
> > Basically you are acknowledging that nobody cares deeply about the idea
> > I proposed in previous thread (which is probably true) but at the same
>
> I did not say that nobody cares, I said that the thread does not get
> many responses. The reasons can be manifold.
>
> The reason why *I* have not responded is that I was on vacation and had
> an immense workload of projects until the end of the year afterwards. I
> was more or less off as you can see at my engagement in the dev list
> after June.
>
> Others may have had same issues. Sometimes a topic needs patience or
> reminders for the community to pick up.
>
> I care a lot for this topic, which is why I expressed my wish to the
> community to join the discussion on several occasions. We simply have
> different perspectives, which is good IMO. Together with more
> perspectives from others, we will be able to build a clearer picture of
> the vision and an actionable plan to reach its realization.
>
> And I really think that a more detailed roadmap will help to engage more
> people in the collaboration (which would be more fun also).
>
>
> > time you are suggesting me to write a lengthy design/architectural
> > document that will rephrase what as already been said in that thread.
>
> I have suggested to write down and discuss important details and the
> pros/cons of different approaches and ideas. IMO it's the only way to
> engage the community in actionable work items and collaboration. It does
> not necessarily mean that it needs lengthy documents. A simple Wiki page
> would do for a start.
>
> > Sorry but no, I will not write such document, I have already explained
> > multiple times the design principles leading to the proposal of enabling
> > the distribution of OFBiz inside a Jar:
> >
> > - Extensible dependency management is better than having to define a
> >    arbitrary global ordering
> >
> > - Location independent loading/configuration mechanism is the only sane
> >    way to provide true extensibility.
> >
> > - Adopting the stable mechanism provided by the Java platform that we
> >    already depend on is better than implementing our own specific
> >    mechanism
> >
> > If people are not convinced by the benefits of this vision which imply
> > deprecating the “component-load.xml” mechanism and use “depends-on”
> > instead (which I did not introduced in the first place) then providing a
> > precise design/implementation plan will not help moving forward, it will
> > just lead to more time waste on my side.
>
>
> I think depends-on is a point we already have discussed and this was not
> my topic in the latest emails. My proposal to write up a concept is
> adressed to the "big picture" you have described in [1], which contains
> your statement:
>
> "Here is a *big* change that I am considering for OFBiz to fixes those
> issues by leveraging the Java platform which already provides everything
> that we need to fix those issues: ..."
>
> I was talking about this big change and the plan behind it. In the
> initial discussion you gave a brief vision, which should be worked out
> by the community to move forward. A vision is far from a concept the
> community can decide on, which is my main point I expressed earlier.
>
> [2] is the Jira with first changes and commits regarding the big
> picture, which is why I intervened to hold on and talk about the concept
> before changing things in *trunk*.
>
> > I don't see the point of continuing this unproductive discussion neither
> > to proceed with a formal vote regarding the deprecation of
> > “component-load.xml”, because whatever the result I have lost my faith
> > in the capability of this community to succeed at handling the technical
> > challenges that will enable OFBiz to stay relevant in the future.
> >
> > But this is fine.
>
> As I've sorted out the "depends-on" topic as the reason for the wish for
> a concept/plan: do you also think that a discussion about the *big
> change* is unproductive and is not necessary?
>
> How do you do conceptual work with clients or colleagues? I believe
> there is some kind of written documentation and clear decision points
> involved at least for non trivial features/changes.
>
> I sincerely hope that we can sort out the resentments and find a way to
> collaborate on the challenges that lay ahead.
>
> Best regards,
>
> Michael
>
>
> [1] https://s.apache.org/7e590
>
> [2] https://issues.apache.org/jira/browse/OFBIZ-11161
>
> [3]
> https://lists.apache.org/thread.html/re7d18081eea709568ad6b1076dcd7464fe750107e222dada0b4994a2%40%3Cdev.ofbiz.apache.org%3E
>
>
>
>

[Mathieu Lirzin]

Michael Brohl <[hidden email]> writes:

> I think depends-on is a point we already have discussed and this was
> not my topic in the latest emails. My proposal to write up a concept
> is adressed to the "big picture" you have described in [1], which
> contains your statement:
>
> "Here is a *big* change that I am considering for OFBiz to fixes those
> issues by leveraging the Java platform which already provides
> everything that we need to fix those issues: ..."
>
> I was talking about this big change and the plan behind it. In the
> initial discussion you gave a brief vision, which should be worked out
> by the community to move forward. A vision is far from a concept the
> community can decide on, which is my main point I expressed earlier.

If we failed to understand each other on the small picture, I doubt
bringing the “big picture” will be lead to better result. The bigger the
scope is the more likely it will end up in a “what if” tar pit.

>> I don't see the point of continuing this unproductive discussion neither
>> to proceed with a formal vote regarding the deprecation of
>> “component-load.xml”, because whatever the result I have lost my faith
>> in the capability of this community to succeed at handling the technical
>> challenges that will enable OFBiz to stay relevant in the future.
>>
>> But this is fine.
>
> As I've sorted out the "depends-on" topic as the reason for the wish
> for a concept/plan: do you also think that a discussion about the *big
> change* is unproductive and is not necessary?

Maybe a few month ago I would have been more patient and open to get
into the requirement analysis details, but now that I have already spent
all my energy into related heated debates without having any time left
on realizing what I intended to work on initially, I am basically done.

It could have been productive but in an alternate reality.

> How do you do conceptual work with clients or colleagues? I believe
> there is some kind of written documentation and clear decision points
> involved at least for non trivial features/changes.

Usually such discussion involves a whiteboard and a face-to-face
discussion. Nereide has not a strong culture of written specifications
and work in a very agile way.

> I sincerely hope that we can sort out the resentments and find a way
> to collaborate on the challenges that lay ahead.

I am afraid that I am out of fuel here.

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

[Mathieu Lirzin]

Hello Taher,

Taher Alkhateeb <[hidden email]> writes:

> I can sense frustration from Mathieu regarding getting things moving
> forward.

You are correct.

> I would just like to note that it's really not _that_ bad!  You've
> already gotten a lot of commits rolling into the code base (which is
> fantastic) and you didn't get objections on most of them. In fact many
> commits that you made were just fine, including things you did to the
> core components and gradle scripts and whatnot.

Yes I am glad about that. However such achievement has been possible
only because I chosed to move fast for changes I considered as implicit
implementation details. Apparently such practice do not follow the
recommended guidelines which require a code change proposal to be slowly
reviewed first even for trivial stuff because we can never know if it
might break user code or not.

> So I want to encourage you to trust that things would work themselves
> out, and there is no need to be frustrated. Take a deep breath and
> just consider more of a long-term initiative than a short term one.
> Doing the jar architecture is not the only thing that can be improved.
> There is a whole heap of areas in the framework that can be improved.
> For example REST (which you worked on partially if I'm not mistaken).

The global goal is not just to improve various areas for the sake of
improving them. The objective is to end up with a piece of software that
is useable, extensible and works reliably.

I tried my best to implement the REST stuff (and Artemiy after me)
without going as far as I intended because I faced the immense
complexity of ‘RequestHandler#doRequest’ which involves complex
mechanisms like “override view URI”, ad-hoc redirection, messy error
handling, HTTP query parameter passed in the path with a ‘~’ prefix
which are used in templated links inside Freemarker code... all that
paired with the unbearable complexity of the screen DSL to implement a
JSON view handler...  Clearly I am not convinced that following that
approach will eventually turn into something useable and reliable in the
long run.

Thank you anyway Taher for trying to find something positive within a
failure. :-)

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

[Nicolas Malin-2]

Hi,

On 05/02/2020 22:10, Mathieu Lirzin wrote:

How do you do conceptual work with clients or colleagues? I believe
there is some kind of written documentation and clear decision points
involved at least for non trivial features/changes.

Usually such discussion involves a whiteboard and a face-to-face
discussion. Nereide has not a strong culture of written specifications
and work in a very agile way.

Mathieu was ahead of my response :)

I can complete with: Nereide lost written specifications culture, for the benefits of humans and projects.

From own part, we think that is preferable to ensure on respect some principles and trustfully to developer because when he work on subject it's always to improve a project, not just waste is time for pleasure (I talk about Nereide's project)

This is the main reason that these lasts years, we can move forward and grow own production quality level with propagating many improvement to community.

I encourage my colleagues to contribute on trunk to expose as soon as own work for other, they are not risk for customer site with the release process, and with the long time that we have between each branch release, each commiter have the time to adjust the taffy.

Nicolas