Allow to load plugin with same artifactIds/PluginIds

[dmitry-timofeev]

Overview

It would be wonderful if PluginManager operations identified the plugins by (PluginId, PluginProvider, Version) so that applications can simultaneously work with plugins:

• From different providers (that might pick the same pluginId).
• Of several versions ("foo-plugin" of 1.5.1 and 2.0.1).

The present recommended values for plugin metadata are:

• artifactId for PluginId
• groupId for PluginProvider
• version for PluginVersion

Such values make perfect sense and are easy to understand, however, with pluginId=artifactId the scenarious above do not work.

---

Alternatively, the default recommended value for PluginId might be changed in all examples in documentation to "groupId:artifactId:version" so that it is used by default by the users.

Workaround

Set pluginId to "groupId:artifactId:version" so that it is unique for any plugin.

See also:

• Allow multiple versions of the same plugin #189
• Mailing list discussions

[wolframhaussig]

I think that the parallel loading of plugins with the same pluginId but different providers is a real usecase(e.g. having a db-support-plugin from both com.oracle and com.microsoft) but I do not see the real benefit of loading different versions here.

Also, I see a problem of backwards-compatibility here - if we have a Map<PluginId, PluginWrapper> in AbstractPluginManager which allows having the same pluginName what would public PluginWrapper getPlugin(String pluginId) return when a duplicate pluginName is given? I think this would be best handled in #372 so we can switch from public PluginWrapper getPlugin(String pluginId) to public PluginWrapper getPlugin(PluginId pluginId).

[decebals]

Maybe the simple solution in this case is to use a more complicated pattern for pluginId (a package name or groupId + artifactId). In the end is a matter of convention and application organization. Using Maven or Gradle I think that the pluginId = groupId + artifactId can be done automatically.

[wolframhaussig]

You are right, there is just the benefit of having a few quality of life features, e.g.:

• start/stop all plugins from a provider
• whitelist/blacklist providers in enabled.txt / disabled.txt
• ...

Of course, one could always implement something like this yourself but it would be harder because the pluginId string would have to be parsed and checked(e.g. some plugin providers only use the pluginId itself, some use provider-pluginId while others use provider:pluginId, ...)

[decebals]

because the pluginId string would have to be parsed and checked

Why the pluginId string should be parsed? In the end it's about convention/rule. For example in Java Module for module name we have java.xml, jdk.charsets. It's more or less mandatory to include a namespace as prefix (root package name, organization id, ...). We will see in the future if we should do something related this topic (some constrain or similar), when we will have a concrete situation.