Download via kpm plugin fails if the plugin naming convention is different

[reshmabidikar]

The KPM plugin code tries to guess the artifactId by convention (PluginNamingResolver.of(pluginKey).getPluginName()). However, if the convention isn't respected, the download fails. If the caller has specified pluginArtifactId, the plugin should trust the caller and use the specified pluginArtifactId instead of guessing. The code should also be made more robust so that it works even when one of pluginKey, artifactId, and version is not specified. This fix would need to be implemented carefully taking into consideration all the possible combinations of pluginKey, artifactId, and version.

More details in https://github.com/killbill/technical-support/issues/134

[xsalefter]

(I know that we already spent so much time making this 😬 , but,) I think we need to introduce breaking changes and remove pluginKey and/or pluginName support. I guess pluginName/pluginKey introduced because we need to support plugin written by Ruby, but AFAIK this is not supported anymore. Also, I know we have this in documentation:

.... but we have no way to enforce that convention for third party plugins ....

Or we can define restrictive set of rules about this. I'm proposing that we just adopt maven repository structure.

In implementation PoV, I thinking:

1. Use <maven-group-id>:<maven-artifact-id> as pluginKey format (like Gradle file for defining dependency).
2. Making this "pluginKey" mandatory.

I imagine this will reduce the needed of searching which one from combination of pluginKey/artifactId/version that is correct and which one need precedence over the other.

WDYT?