I am +1, as it is going to provide more clarity and devops simplicity for adopters
Best regards, Pierre Smits *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) since 2008* Apache Steve <https://steve.apache.org>, committer On Sun, Dec 8, 2019 at 2:34 AM Mathieu Lirzin <mathieu.lir...@nereide.fr> wrote: > 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. > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 >
