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

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

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

Hello Taher, Taher Alkhateeb 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

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

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

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

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

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

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 writes: Am 31.01.20 um 13:15 schrieb Jacques Le Roux: We could continue the

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

Hello, Michael Brohl 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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Le 30/01/2020 à 17:51, Mathieu Lirzin a écrit : Jacques Le Roux 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

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

Jacques Le Roux 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.

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

Hi Mathieu Le 29/01/2020 à 22:26, Mathieu Lirzin a écrit : Hello Jacques, Jacques Le Roux 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,

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

Hello Jacques, Jacques Le Roux 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,

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

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,

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

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 wrote: > Hi Mathieu, Samuel, > > You were the most visible proponents of this. After 5 days w/o exchanges > should we consider the idea is

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

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 

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

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.

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

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

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

Hi All, Since it's impossible to have both features (ie “base/config/component-load.xml” and 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

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

I am +1, as it is going to provide more clarity and devops simplicity for adopters Best regards, Pierre Smits *Apache Trafodion , Vice President* *Apache Directory , PMC Member* Apache Incubator ,

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

Hi Michael, First I must say that I understand your POV about production and custom projects. I have been there too and when your business depends on it, things really matter. That's why I suggested that we could have both solutions in parallel for a while. With the current one being

What is OFBiz public API? (was: Removing “base/config/component-load.xml”)

Hello, The arguments provided by Michael are very general and go beyond the specific question of “component-load.xml” so I am opening a general discussion about how to make OFBiz evolve smoothly by precising the extent of its public API. I urge other contributors to join this discussion which is

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

Hi Mathieu, citing myself from the comment in https://issues.apache.org/jira/browse/OFBIZ-11296: Mathieu Lirzin, please consider that people have limited time and that they have to put priorities on how they spent it. Putting pressure on (non bugfixing) issues does not help good

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

Jacques Le Roux writes: > Mathieu asks Michael to provide  an "explanation regarding why it > matters in production environments to be able to patch" > component-load.xml files @Michael: ping -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37

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

Hi Taher, Actually it has already been reverted Jacques Le 19/12/2019 à 12:04, Taher Alkhateeb a écrit : Also, if there are disagreements on a direction among members then it is usually the case that a -1 from a binding vote requires a revert and starting a discussion. Then we can either have

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

Also, if there are disagreements on a direction among members then it is usually the case that a -1 from a binding vote requires a revert and starting a discussion. Then we can either have consensus, lazy consensus or the issue is shut down. I'm saying what should be done, just laying out the

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

May I suggest inquiring from the community on whether this feature is important to them? Pehaps on user@? This way maybe we can have a more informed decision on whether to adopt this change. On Thu, Dec 19, 2019, 10:13 AM Jacques Le Roux wrote: > Le 18/12/2019 à 21:09, Jacques Le Roux a écrit :

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

Le 18/12/2019 à 21:09, Jacques Le Roux a écrit : Hi Samuel, All, Le 18/12/2019 à 14:00, Samuel Trégouët a écrit : Le 18/12/2019 à 12:09, Jacques Le Roux a écrit : Mathieu asks Michael to provide  an "explanation regarding why it matters in production environments to be able to patch"

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

Hi Samuel, All, Le 18/12/2019 à 14:00, Samuel Trégouët a écrit : For the new feature itself, it seems wise to me to have it working with component-load.xml files before starting it on the trunk... It is working with component-load.xml from the start! but not with framework, applications

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

Hi all, Quoting Jacques Le Roux (2019-12-18 12:39:56) > OK, I sent this message before seeing Mathieu's last one. I guess the revert > Mathieu should close this discussion. I suggest to create a new one about > feature forking (please stop this one). feature forking is another discussion =>

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

OK, I sent this message before seeing Mathieu's last one. I guess the revert Mathieu should close this discussion. I suggest to create a new one about feature forking (please stop this one). I must say I'm strongly against feature forking. I have already explained myself why several times. I

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

Hi, In this thread I superficially see a conversation where no one listens to anyone else's point of view. If I dig a bit more I see Mathieu's perspective who wants to achieve something new which depends on the discussed subject (his [1] below). And Michael's perspective who worries about

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

Hello Michael, Michael Brohl writes: > inline... > > Am 18.12.19 um 00:01 schrieb Mathieu Lirzin: >> Hello, >> >> @Michael: I would like to know if you intend to provide an explanation >> regarding why it matters in production environments to be able to patch >> “framework/component-load.xml”

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

Hi Mathieu, inline... Am 18.12.19 um 00:01 schrieb Mathieu Lirzin: Hello, @Michael: I would like to know if you intend to provide an explanation regarding why it matters in production environments to be able to patch “framework/component-load.xml” and “applications/component-load.xml” ? This

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

documentation, reverting, migration guide, ...). Sorry if I am pressing you but I need that the discussion moves forward. If not I would like to refocus the discussion on the next step which is about the propositions of: 1. Removing “base/config/component-load.xml” and hard-code the ["fram

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

Hello Michael, Michael Brohl writes: > I am still not sure why we need the new mechanism. > > And if we decide to use both, we should make sure that the old version > is the default at least for the lifecycle of one release with proper > an clear dopcumentation for users. > > Thanks, > >

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

I am still not sure why we need the new mechanism. And if we decide to use both, we should make sure that the old version is the default at least for the lifecycle of one release with proper an clear dopcumentation for users. Thanks, Michael PS: I'm asking myself why some people have such

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

Hi All, Have we a lazy consensus here? Jacques Le 10/12/2019 à 06:17, Jacques Le Roux a écrit : Hi Michael, Mathieu, Why not keeping both features and have a simple way (if it does not exist yet) to choose the one to use? BTW Michael,  you are certainly aware, you have a mail certificate

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

Hi Michael, Mathieu, Why not keeping both features and have a simple way (if it does not exist yet) to choose the one to use? BTW Michael,  you are certainly aware, you have a mail certificate issue. Thanks Jacques Le 09/12/2019 à 08:08, Michael Brohl a écrit : Hi Mathieu, inline...

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

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

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

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

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

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

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

Michael Brohl writes: > I was in fact asking for the discussion and review process to the > changes already introduced and committed in the mentioned Jira. OK > It's a good approach to let fellow committers review such work before > it gets committed to the codebase. I agree in theory, but

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

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

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

Hi Mathieu, I was in fact asking for the discussion and review process to the changes already introduced and committed in the mentioned Jira. It's a good approach to let fellow committers review such work before it gets committed to the codebase. This change will affect existing productive

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

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

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

Hi Mathieu, can you please point me to the discussion where this important change was discussed before it was introduced? I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296 which was closed only hours after it was created. I was a bit off lately, maybe I missed

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

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