Even though the vote isn't finished I've taken the risk to implement this today
(as you may have seen with the commits).
Since we're just starting 3.3M1 we have some time to roll it back if some committer
doesn't agree.
Thanks
-Vincent
On Oct 14, 2011, at 9:53 AM, Vincent Massol wrote:
Hi devs,
I'd like to propose to improve the Component Override mechanism (currently based on
component-overrides.txt, see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOver…). We have
a limitation right now in that we can only have one level of override. The issue is that
we need more levels even right now since we have component impls in xwiki-commons or
xwiki-rendering that are overridden in xwiki-platform (thus using
component-overrides.txt). This means that users cannot provide their own implementations.
Thus I'd like to propose the following:
* Deprecate the component-overrides.txt file
* Add an optional priority level number that you can specify in the components.txt
* I propose the following format in components.txt: <priority level>:<full
package path to implementation as it is now>. Ex:
1000:org.xwiki.rendering.internal.macro.DefaultMacroManager
* Use a default priority of 1000 when not specified (same as for our Macro)
* Guarantee in the documentation that all components that the XWiki project provides
never have priorities under, say, 100. This is so that users who want to override know
that if they use a priority under 100 their impls will always win.
* Use a priority of 500 in platform when overriding components found in commons or
rendering.
Here's my +1
Thanks
-Vincent