This can happen when invoking a plugin from the command line by giving only its prefix instead of its group and artifact id, e.g. in mvn help:effective-pom the token help is the plugin prefix and can serve as an abbreviation of org.apache.maven.plugins:maven-help-plugin. Resolution of a plugin prefix can fail for a couple of reasons:
- You are referring to a non-existing plugin, e.g. due to a typo in its prefix.
- You are using a third-party Maven plugin that is not deployed to the central Maven repository and your POM/settings is missing the required
<pluginRepository>to download the plugin. Note that<repository>declarations are not considered when looking for the plugin version, only<pluginRepositories>are searched for plugins. - The plugin repository you have configured requires authentication and Maven failed to provide the correct credentials to the server. In this case, make sure your
${user.home}/.m2/settings.xmlcontains a<server>declaration whose<id>matches the<id>of the plugin repository to use. See the Maven Settings Reference for more details. - Your settings do not list the required
<pluginGroup>. When resolving a plugin prefix, Maven does not search the entire repository but only specific group ids given by<pluginGroups>. If the group id of the desired plugin is neither listed here nor given in your POM, the plugin will not be found. See the Maven Settings Reference for more details. - The metadata listing the available plugins in a group is broken. For each configured plugin repository, Maven will try to download a file named
maven-metadata.xml. If those files are not properly maintained or get corrupted upon download, the prefix resolution can fail.
In case of any of the first four scenarios, check your command line, POM and/or settings for the proper contents. If you configured the plugin repository in a profile of your settings.xml, also verify that this profile gets actually activated, e.g. via invoking mvn help:active-profiles.
Regarding case 4, you have the choice to either add the <pluginGroup> to your setting.xml or to declare the desired <plugin> in the plugin management section of your POM. The first approach works for all your projects but requires each developer to do the same on his machine. The second approach can be easily shared with other team members via the source control management but applies only to the POM in question and all POMs that inherit from it.
To check whether the metadata files are intact, browse your local repository which is usually located at ${user.home}/.m2/repository. For the group id com.company, the files to check are com/company/maven-metadata-<repository-id>.xml where <repository-id> indicates the repository from which the file was downloaded. If this file doesn't match the copy in the plugin repository, simply delete the local file and have Maven re-download it. If the maven-metadata.xml in the plugin repository itself appears to be broken, please report this to the maintainer of the plugin.