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 <michael.br...@ecomify.de> 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 <michael.br...@ecomify.de> 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 > > > >
