Re: What is OFBiz public API?
Hi Mathieu, inline... Am 05.01.20 um 18:32 schrieb Mathieu Lirzin: 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 crucial to define our capability to work together as a community and my willing to continue to participate. Michael Brohl writes: This project is not only about tech, it has a user base with serious business running on base of OFBiz. This has always to be considered as serious as good technical solutions should be considered. So we cannot simply change things because single contributors like other technical solutions better. We have to remain downwards compatible and manage deprecation of features carefully. First to clarify things, making evolutions in the framework is not about developers changing arbitrary stuff, it is about structuring internals in an understandeable way to enable correctness and the inclusion of new features that satisfies evolving requirements. Backwards compability only makes sense when something has a public API otherwise every evolution is a breaking change. In OFBiz we lack a proper specification of what is a feature provided by the framework subject to backward compatibility and what is an implementation detail that can evolve/disappear between version silently. We rely on an informal consensus to distinguish between the two. The fact that some mechanism appears to be used in production is a valid argument against its removal only if that mechanism is part of the public API, otherwise it is up to the client code to adapt. OFBiz is not just a library or core framework, it is a multi-level project: * a web development framework * a web based ERP system on base of this framework * highly flexible and extendable through various mechanisms. OFBiz users are service providers, utilizing OFBiz to provide software solutions as well as end users who are mainly using the applications. There's also a mix in the case where company employees use OFBiz as a web development framework to provide software solutions for their own company. So it cannot be simplified to a scenario where the framework is "ours" and the users are proivided with the applications and a public API. So if the project has provided a mechanism to configure how components are loaded, we are also responsible for taking care of this if we want to make changes. My broad understanding of what is part of OFBiz public API is: - the plugin mechanism - the data model and data access (Entity Engine) - The ability to call existing services and implement new ones (Service Engine) - the HTTP routing mechanism (Event Handler) - the various configuration files location in “{component}/config” directories. The component-load.xml is also a configuration option which is utilized in projects. There is some documentation on how to utilize OFBiz as a core framework by deactivating all components (old but still valid, see [1]). [...] If you read carefully what I previously wrote, there are several uses for the applications component-load.xml: * deactivation of unused component(s) by commenting out the load-component entry (why load marketing resources if you don't use the component at the moment) * addition of components (yes, I've seen projects where this was not done through the hot-deploy mechanism) * ordering these components in the right load order While you can argument that these might be "wrong" approaches, they are technically valid and used in customer projects. Therefore we cannot simply switch the mechanisms without a proper deprecation period. The general problem here is not to know if things are wrong or technically valid, it is to know if something is part of the public API or is an implementation detail. This determines how to handle an evolution on that part. Something wrong but part of the public API like using XML for code should be handled with care (deprecation, migration guides), but something technically valid but inappropriate like patching framework Java source code from a plugin should be ignored. I don't think that patching Java code is/was part of the initial discussion. We should not mix up things. In the case of ordering/enabling core components I consider it as an implementation detail. If a component inside framework/applications is I don't agree, see above. 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
Fwd: Returned mail: see transcript for details
Let's try again (forwarding)... (I copy the SMTP issue too in case it could be of help later) Message transféré Sujet : Returned mail: see transcript for details Date : Sun, 5 Jan 2020 20:34:06 +0100 (CET) De :Mail Delivery Subsystem Pour : jacques.le.r...@les7arts.com The original message was received at Sun, 5 Jan 2020 20:33:04 +0100 (CET) from mail-green-smtp1.local [192.168.42.81] - The following addresses had permanent fatal errors - (reason: 550 5.7.1 Service unavailable; client [185.20.84.5] blocked using b.barracudacentral.org) - Transcript of session follows - ... while talking to mx1-he-de.apache.org.: RCPT To: <<< 550 5.7.1 Service unavailable; client [185.20.84.5] blocked using b.barracudacentral.org 550 5.1.1 ... User unknown DATA <<< 554 5.5.1 Error: no valid recipients Reporting-MTA: dns; smtp5.mailout.nfrance.com Arrival-Date: Sun, 5 Jan 2020 20:33:04 +0100 (CET) Final-Recipient: RFC822;dev@ofbiz.apache.org Action: failed Status: 5.7.1 Remote-MTA: DNS; mx1-he-de.apache.org Diagnostic-Code: SMTP; 550 5.7.1 Service unavailable; client [185.20.84.5] blocked using b.barracudacentral.org Last-Attempt-Date: Sun, 5 Jan 2020 20:34:06 +0100 (CET) Re: What is OFBiz public API?.eml Sujet : Re: What is OFBiz public API? De : Jacques Le Roux Date : 05/01/2020 à 20:33 Pour : dev@ofbiz.apache.org Hi Mathieu, Inline too... Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit : 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 crucial to define our capability to work together as a community and my willing to continue to participate. Michael Brohl writes: This project is not only about tech, it has a user base with serious business running on base of OFBiz. This has always to be considered as serious as good technical solutions should be considered. So we cannot simply change things because single contributors like other technical solutions better. We have to remain downwards compatible and manage deprecation of features carefully. First to clarify things, making evolutions in the framework is not about developers changing arbitrary stuff, it is about structuring internals in an understandeable way to enable correctness and the inclusion of new features that satisfies evolving requirements. Maybe you could clarify what you want to achieve. I have the feeling that you have a long term view and the “component-load.xml change” is only a step, right? Backwards compability only makes sense when something has a public API otherwise every evolution is a breaking change. In OFBiz we lack a proper specification of what is a feature provided by the framework subject to backward compatibility and what is an implementation detail that can evolve/disappear between version silently. We rely on an informal consensus to distinguish between the two. The fact that some mechanism appears to be used in production is a valid argument against its removal only if that mechanism is part of the public API, otherwise it is up to the client code to adapt. I agree, that's why I asked Michael, in answer to his last email, if he could adapt his mechanism to "generate the resulting component-load.xml at build time" using the new proposed mechanism. Of course it would not longer relies on the component-load.xml file (to be eventually removed) but on the new mechanism. My broad understanding of what is part of OFBiz public API is: - the plugin mechanism - the data model and data access (Entity Engine) - The ability to call existing services and implement new ones (Service Engine) - the HTTP routing mechanism (Event Handler) - the various configuration files location in “{component}/config” directories. I think there are more, but those are part of it. [...] If you read carefully what I previously wrote, there are several uses for the applications component-load.xml: * deactivation of unused component(s) by commenting out the load-component entry (why load marketing resources if you don't use the component at the moment) * addition of components (yes, I've seen projects where this was not done through the hot-deploy mechanism) * ordering these components in the right load order While you can argument that these might be "wrong" approaches, they are technically valid and used in customer projects. Therefore we cannot simply switch the mechanisms without a proper deprecation period. The general problem here is not to know if things are wrong or technically valid, it is to know if something is part of the public API or is an implementation detail. This determines how to handle an evolution on that part. Something wrong but part of the public API like using XML for code
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 deprecated and the new one replacing it w/o hurry. So the 1st question is to know if that's possible. I could be wrong, but I vaguely recall that Mathieu said it was possible. Once that clarified the debate should cool down. Before answering to Mathieu's last message, I'd like to note inline some points about yours. Le 04/01/2020 à 15:47, Michael Brohl a écrit : Hi Mathieu, If you read carefully what I previously wrote, there are several uses for the applications component-load.xml: * deactivation of unused component(s) by commenting out the load-component entry (why load marketing resources if you don't use the component at the moment) Here I agree about Mathieu's perspective (in his last email). If an applications component can easily be put out by commenting out the load-component entry, it should not be in application but in plugins. Only mandatory applications should be in under the applications directory. * addition of components (yes, I've seen projects where this was not done through the hot-deploy mechanism) This is no good and should not be done this way * ordering these components in the right load order While you can argument that these might be "wrong" approaches, they are technically valid and used in customer projects. Therefore we cannot simply switch the mechanisms without a proper deprecation period. As I said earlier I agree about a proper deprecation period. For the plugins, all the above use cases are common in our projects. We also use a multi-level configuration mechanism (standard default - custom standard default - project default and targeted systems) where we are able to do fine-grained configurations and generate the resulting component-load.xml at build time. Is this not the main reason about your concerns on Mathieu's changes? Can't this be migrated using Mathieu's proposed solutions? My proposal would be to actively ask other contributors with significant project experience for their input before re-commiting anything. I don't see any problems about committing new stuff as long as they don't disturb current functional behaviours. Note that those should be done in trunk, and we are not supposed to use the trunk in production. So the impact should not be for today. If we refer to our current stable version it would be at least 3 years before those being released... Would that not be a reasonable deprecation period? If there is a demand for yur solution, I would also propose to make the solution compatible with the component-load mechanism and leave the old component-load.xml in place, together with a deprecation announcement and proper documentation on how to migrate. That sounds reasonable to me This would introduce the new depends-on in the next release It would not be the next release, but one in at least 3 years... but does not change anything for existing users if they want to stick with the component-load mechanism. Here we need to know if the cost of maintaining both solutions is worth it. At some point a deprecated mechanism can be removed if the newer solutions offers more flexibility, better code, etc. For the plugins, I object to introduce the mechanism at all for the above stated reasons. Could you elaborate on that, I don't get it Thanks Jacques I hope this explains my point of view clear enough, please ask if it does not. Thanks, Michael Am 14.12.19 um 00:28 schrieb Mathieu Lirzin: 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, Michael PS: I'm asking myself why some people have such a big problem reverting their work if others object against it. If there was no review/discussion/consensus for a new feature, it should simply not go into the codebase and should at least be reverted if there are objections. It's tiring to discuss this afterwards and if the people objecting are not persistent enough, the code simply stays. I have personally no problem reverting things. If you look at the ‘git log’ you will see some recent reverts I have made. I just need to understand the actual objection before reverting [1]. Since your argument seems to be about the “impacts on users” an explanation regarding what you or others are actually achieving when patching the “framework/component-load.xml” and “applications/component-load.xml” would help me understand the issue, because I honestly do not see why the loading order/mechanism of “framework” or “applications” should n
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 crucial to define our capability to work together as a community and my willing to continue to participate. Michael Brohl writes: > This project is not only about tech, it has a user base with serious > business running on base of OFBiz. This has always to be considered as > serious as good technical solutions should be considered. So we cannot > simply change things because single contributors like other technical > solutions better. We have to remain downwards compatible and manage > deprecation of features carefully. First to clarify things, making evolutions in the framework is not about developers changing arbitrary stuff, it is about structuring internals in an understandeable way to enable correctness and the inclusion of new features that satisfies evolving requirements. Backwards compability only makes sense when something has a public API otherwise every evolution is a breaking change. In OFBiz we lack a proper specification of what is a feature provided by the framework subject to backward compatibility and what is an implementation detail that can evolve/disappear between version silently. We rely on an informal consensus to distinguish between the two. The fact that some mechanism appears to be used in production is a valid argument against its removal only if that mechanism is part of the public API, otherwise it is up to the client code to adapt. My broad understanding of what is part of OFBiz public API is: - the plugin mechanism - the data model and data access (Entity Engine) - The ability to call existing services and implement new ones (Service Engine) - the HTTP routing mechanism (Event Handler) - the various configuration files location in “{component}/config” directories. > [...] > If you read carefully what I previously wrote, there are several uses > for the applications component-load.xml: > > * deactivation of unused component(s) by commenting out the >load-component entry (why load marketing resources if you don't use >the component at the moment) > * addition of components (yes, I've seen projects where this was not >done through the hot-deploy mechanism) > * ordering these components in the right load order > > While you can argument that these might be "wrong" approaches, they > are technically valid and used in customer projects. Therefore we > cannot simply switch the mechanisms without a proper deprecation > period. The general problem here is not to know if things are wrong or technically valid, it is to know if something is part of the public API or is an implementation detail. This determines how to handle an evolution on that part. Something wrong but part of the public API like using XML for code should be handled with care (deprecation, migration guides), but something technically valid but inappropriate like patching framework Java source code from a plugin should be ignored. In the case of ordering/enabling core components I consider it as an implementation detail. If a component inside framework/applications is 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 not be entitled to think that they can freely desactivate/reorder/add new components inside the framework/applications directory and that such modifications will continue to work in a future release. The larger question is about knowing if the internal organisation of the files inside the "framework/applications" directories with the exception of the “config” directories is considered part of OFBiz public API or not? What do people think? For the record, Without the ability to safely refactor a large subset of the codebase that have the status of “implementation details”, I will simply stop contributing to OFBiz because I don't have time for endless discussions with people blaming my community work because their extensions happen to rely on unspecified behavior. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37