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 <michael.br...@ecomify.de> 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 not be possible anymore.
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.
Users are also developers using OFBiz as a framework, so we should take responsibility for this also.
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?
See my comments above. We cannot reduce the discussion to a public API because of the web development framework functionality provided by OFBiz.
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.
Noone is blaming your work. In the contrary, I expressed my appreciation for your work in the beginning of this discussion.
A community project is serving a lot of different interests and is natural that changes will bring up discussions. It is also natural that improvements and chnages must be thoroughly discussed and decided. Different people have different views on the project and in my opinion, the best solutions come up if different people engage in the discussion to find the best solution, both technically and functionally.
So it is essential that you are open for discussions and take into account that things do not go through easily. It's in the best interest of the project.
The depends-on discussion has shown this clearly: without my objection, the regression put in the first implementation would have gone through and potentially break productive projects after release.
Pressing people by rusing things into the codebase or even expressing that you are not willing to contribute if you don't get your work into the codebase easily does not help much to solve the challenges which lie ahead uf us.
So I really hope that we can find a way for good collaboration and that you can be patient enough to find the best solutions.
Thank you, Michael[1] https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+10.04
smime.p7s
Description: S/MIME Cryptographic Signature
