Virtual extensions

Last modified by Thomas Mortagne on 2018/03/21 12:22

The idea is to indicate in an extension a list of provided "features". Then when resolving extensions dependencies the dependencies ids are be matched in this list.

Use cases

Renamed extensions

Sometime we rename an extension id for various reasons. The problem in this case is that Extension Manager does not know it actually already have a more recent version of the required dependency before it does not have the same id anymore. With virtual package the new version will be able to provide as virtual extension its old id. In this case it's used as alias.

A good example of that is com.xpn.xwiki.platform:xwiki-core which was renamed to org.xwiki.platform:xwiki-platform-oldcore in XWiki 3.1 and a lot of extensions are still depending on com.xpn.xwiki.platform:xwiki-core so when you try to install such an extension in XWiki 3.1 for example, the Extension Manager will download com.xpn.xwiki.platform:xwiki-core 3.0 and loads it and so breaks most of the extensions which actually depend on new APIs introduced in 3.1 as well as duplicating lots of useless services, etc...

Various implementation of the same API

Usually an extension only depends on API since it does not needs anything else to build and it should give its user the choice of the implementation to use. For example a lots of extension are using cache API and then the distribution choose if it will use JBossCache or OSCache implementation of the XWiki cache API. The idea here is to make every cache API implementations extensions provide a common feature which allow EM to know they are implementations for the cache API and automatically download them when an extension depending on cache API is installed.

Custom Maven property

To add support for virtual extensions in a maven project/repository you can extends the pom.xml with a xwiki.extension.features property listing all the features supported by this extension. Features are coma separated and white spaces are not taken into account so you can format your list the way you want.

Version different from the extension version

Since 8.0 each feature has it's own version (by default the version of the extension). In Maven it's indicated with the following syntax feature/version and can be useful when some embedded extension is not in synch with the extension or if new version of an extension decide to start from 1.0 version for some reason (new extension but covert some old thing that should not be installed at the same time, etc.).

Inject features

Since 10.2RC1 it's possible to inject additional features to an extension coming from a repository or a core extension. It's useful when you want to make sure an extension you don't control will be recognized as the same thing than one that does not have the same id (some extension that have a different id in more recent version, incompatible extensions, etc.).

To do that you need to created a component implementing org.xwiki.extension.ExtensionFeaturesInjector role.

Tags:
    

Get Connected