Fwd: Re: What is OFBiz public API?

[Jacques Le Roux]

(re)Forwarded at Michael's request


-------- Message transféré --------
Sujet : Re: What is OFBiz public API?
Date : Sun, 5 Jan 2020 20:33:03 +0100
De : Jacques Le Roux <[hidden email]>
Organisation : Les Arts Informatiques
Pour : [hidden email]



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 <[hidden email]> 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, 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 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.

Fortunately I have never seen "patched framework Java source code from a plugin" :), but I agree about the idea.


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

+1


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

+1


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

It should not be but, as with other aspects in OFBiz, it's still a problem


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

For the current case, the most important question is to know if both solutions could work at the same time, and if yes at which cost? Have you an idea
about that?

Thanks

Jacques

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux <[hidden email]> writes:

> Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
>>
>> Michael Brohl <[hidden email]> 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?

Yes I am/was working on the support of Jar distribution of OFBiz
allowing to separate the source code and compilation process of the
framework from the development of plugins. Basically it means
transforming OFBiz from a project template into a library to improve the
extensibility and reusability of both the framework and the plugins.

Moreover this work is contributing to the effort of facilitating the
deployment of OFBiz in production environments (in the continuity of
‘gradlew distTar’) by allowing the move of specific configuration out of
the source tree and deploying every resources inside the Jar.

I have described the rationale for this work in [1].

> [...]
>> 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.
>
> For the current case, the most important question is to know if both
> solutions could work at the same time, and if yes at which cost? Have
> you an idea about that?

Sure we can keep both options which is the easy way to settle a
disagreement in the short term, I have allowed this in my last patch on
OFBIZ-11296 [2] by supporting both <depends-on> and “component-load.xml”
at the same time with a priority on “component-load.xml”.

However to be able to continue the work of [1] it is important to remove
the usage of “component-load.xml” inside the framework.

[1] https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E
[2] https://issues.apache.org/jira/secure/attachment/12989898/12989898_OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Jacques Le Roux]

Thanks Mathieu,

It's quite clear to me now

Jacques

Le 11/01/2020 à 21:52, Mathieu Lirzin a écrit :

> Hello Jacques,
>
> Jacques Le Roux <[hidden email]> writes:
>
>> Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
>>> Michael Brohl <[hidden email]> 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?
> Yes I am/was working on the support of Jar distribution of OFBiz
> allowing to separate the source code and compilation process of the
> framework from the development of plugins. Basically it means
> transforming OFBiz from a project template into a library to improve the
> extensibility and reusability of both the framework and the plugins.
>
> Moreover this work is contributing to the effort of facilitating the
> deployment of OFBiz in production environments (in the continuity of
> ‘gradlew distTar’) by allowing the move of specific configuration out of
> the source tree and deploying every resources inside the Jar.
>
> I have described the rationale for this work in [1].
>
>> [...]
>>> 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.
>> For the current case, the most important question is to know if both
>> solutions could work at the same time, and if yes at which cost? Have
>> you an idea about that?
> Sure we can keep both options which is the easy way to settle a
> disagreement in the short term, I have allowed this in my last patch on
> OFBIZ-11296 [2] by supporting both <depends-on> and “component-load.xml”
> at the same time with a priority on “component-load.xml”.
>
> However to be able to continue the work of [1] it is important to remove
> the usage of “component-load.xml” inside the framework.
>
> [1] https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E
> [2] https://issues.apache.org/jira/secure/attachment/12989898/12989898_OFBIZ-11296_ignore-depends-on-when-a-component-load.xml-is-prese.patch
>