As described in CE-4, attempting to install Gliffy for Confluence in UPM 2.17.5 and above results in an error message, even though the installation actually succeeds.
Gliffy is packaged as an OBR. I believe the problem here is that the OSGi bundle name, "com.gliffy.plugin.confluence.gliffy-confluence-plugin" (in obr.xml, and in the Bundle-SymbolicName header of the main plugin jar's manifest), does not match the plugin key, "com.gliffy.integration.confluence" (in the Marketplace listing, and in the atlassian-plugin.xml file of the main plugin jar).
Normally, the plugins framework only cares about the plugin key— so it is still possible to install Gliffy, and it should work correctly once it is installed; the framework should be able to maintain the association between the plugin and its OSGi bundle even though the bundle name doesn't match the key.
But one place where UPM looks at the bundle name is when we install an OBR. After installing all the plugin jars from the OBR, UPM checks whether the main plugin is now enabled; it looks it up by plugin key, but the key it's looking for is actually coming from the Bundle-SymbolicName header in the manifest. Since they don't match in this case, it incorrectly tells you that the install failed.
I think it should be possible for UPM to simply look at atlassian-plugin.xml in this case instead of the manifest headers. The original reason we needed to look at the manifest headers was that we need to match the bundle name there against the bundle name in obr.xml, but it should be easy enough to get the plugin key as well.
The logic for this was never correct, but it was only after the fix for that the incorrect plugin-key lookup would have such a visible effect, therefore the problem is only apparent since UPM 2.17.5.