Hello Taher, Taher Alkhateeb <slidingfilame...@gmail.com> writes:
> I was involved in some of the biggest changes in the framework > (gradle, unit tests, start component, core framework, etc ...) and > every time it involved a good deep discussion on the mailing list > trying to reach consensus before implementation. > > So I recommend always treading carefully when doing larger changes and > getting others involved. Sometimes people surprise you with better or > simpler solutions if you give them the opportunity to express their > opinion. This is my perspective too, and every time I feel that an improvement I am considering has a strong impact, I make the effort of sending an email to this ML explaining the problem and asking for feedback on the considered solution. > Now regarding completely replacing the component-load.xml with > depends-on, I'm not sure this makes much sense at the core framework > level for a few reasons: > > - First I don't think this issue is linear. It is possible for > example, to speed up the startup time of the system by running things > in parallel where possible > - Also, the multi-threaded portion of the system (some of it using the > executor framework in java.util.concurrent) needs to be studied > carefully to see how the loading sequence is best optimized > - Finally, I'm just not convinced of either approach (depends-on or > container-load) for core framework functionality. We need a better > solution that handles the core quite differently (without the need for > a component concept). > > So a better refactoring IMHO on the core level involves an > architecture that does not necessarily comply with the component > concept, and we can proceed with the original plan of further breaking > down the system into a core deplorable framework, core components, and > plugins. Since you don't like either solutions and given that currently we have both, wouldn't it be a step forward to get rid of one of them ? :-) IMO the discussion is not about deciding if separating the framework core into multiple components is a good idea or not. We are only discussing if we should remove the “component-load.xml” feature which implies removing an historic configuration mechanism that was providing integrators the capability to use other meta-directories than "framework", "themes", "applications, "plugins" and to define a total order between components in component directories. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
