Hi Mathieu,

can you please point me to the discussion where this important change was discussed before it was introduced?

I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296 which was closed only hours after it was created.

I was a bit off lately, maybe I missed something.

Thank you,

Michael


Am 08.12.19 um 02:34 schrieb Mathieu Lirzin:
Hello,

We have in OFBiz two redundant ways to define the order in which
components are loaded.

* “component-load.xml” files stored in components directories meaning
   directories containing single components. They define a total order
   between every component inside that directory.

* <depends-on> XML elements inside “ofbiz-component.xml” files stating
   that a component ‘c’ requires a set of components ‘D’ to exist and to
   be loaded before trying to load ‘c’.  Globally this constructs a
   dependency graph which defines a partial order between available
   components.

Currently <depends-on> is used everywhere in the framework on ‘trunk’
because it is more declarative and open for extensibility due the
partial ordering capability.

The only exception is “base/config/component-load.xml” which is a
special components directory configuration defining the order of other
components directories meaning “framework”, “themes”, “applications” and
“plugins” in their respective dependency order.

This file allows integrators to add and reorder components
directories. This feature is not really useful nowadays considering that
our plugin mechanism provides sufficient extensibility capability when
combined with <depends-on> definitions.

In order to simplify things which helps the endeavour towards
transforming OFBiz in an extensible JVM based library, I would like to
remove such configuration point and hard-code the list of component
directories inside the code.

I guess this low-level technical proposition is not interesting for most
people but in case someone want to understand more or object before
things are actually removed. I am opening a discussion on this ML.

If nobody step-up in a week, I will go ahead.

Thanks.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to