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 <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.
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.
Hi All,
Following Mathieu's question about "OFBiz public API" and the points he already
mentioned I decided to create a new thread.
I don't know what will happen with the other tread (mostly about
removing/replacing component-load.xml). That's not the subject here.
Mathieu wrote:
<<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 tend to agree with this list. From the top of my head, I'd add (maybe not a
the same level and maybe we need to define level/s)
1. Obviously, the Java API !
2. All things (why not?) supported by XSD files.
It includes Entity and Services Engines, not all feature are
documented/supported by XSD files though.
It also includes component-loader.xsd and ofbiz-component.xsd which are
somehow parts of the subject of the other thread
3. OFBiz Gradle tasks
I don't know what to say about Groovy scripts which are replacing simple-method
services.
What else?
Jacques
