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 <jacques.le.r...@les7arts.com> writes:
Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
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.
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
