On Fri, Oct 14, 2011 at 9:53 AM, Vincent Massol <[email protected]> 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#HOverr...). 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

We could maybe keep this system to allow an admin to choose an implementation he wants whatever the priority setup of each impl. So it would only be used in WEB-INF/classes basically.

* 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

+1

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Hi Vincent, I so agree with the fact that we should be able to override more than once. so +0.5 Besides that, i am a little worried about a "number"-like system because you as a user, never know which numbers are used and which not. But I think it's hard to find a way to do it perfect. Also, I would remark that components.txt becomes a description file and that we invent a syntax for it when there are so many description syntaxes. Thanks, Anca On 10/14/2011 09: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#HOverr...). 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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 10/14/2011 03: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#HOverr...). 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.

+1 for all, except maybe use a priority of 900 in platform overrides. Leaving a gap of 500 is not that useful. Should we allow negative priorities?

Here's my +1

Thanks -Vincent

-- Sergiu Dumitriu http://purl.org/net/sergiu/