reposilite: Maven Help Plugin is not able to browse the repository

Hi there, I am encountering a problem that may be related to this issue. I am writing a shell script that is trying to determine the current version of the POM by running

mvn help:evaluate -Dexpression=project.version

I am getting the following error from maven:

> No plugin found for prefix 'help' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories

I am trying hard to figure out what the actual problem might be. I do not entirely understand what is happening, but it seems, > that maven is trying to download https://<my reposilte mirror>/org/apache/maven/plugins/maven-metadata.xml to figure out what plugins are available for the > help prefix? It then gets confused by what it finds - the content looks somewhat weird; it has actual plugin-names at places > where I think should be version strings – that’s what brought me here, actually. So, reposilite generates the content of this file on the fly?

I am sorry, I do not understanding half of it. Do you think my problem could be related?

– EDIT

Just a quick follow-up: When copy the contents from the original repository over to my local repository (overwriting the cached > version in $HOME/.m2/repositories/org/apache/maven/plugins/maven-metadata-<my reposilite mirror>.xml, the mvn > help:evaluate command executes just fine. So there must be some relation, no?

_Originally posted by @ldegen in https://github.com/dzikoysk/reposilite/issues/461#issuecomment-832790409_

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 18 (10 by maintainers)

Most upvoted comments

There is a misunderstanding, I think. This has nothing to do with the maven-help-plugin, or any other specific plugin.

The problem occurs when the maven cli tries to lookup plugin metadata. E.g. when you run something like mvn foo:bar, maven needs to first figure out which plugin provides the foo-prefix. It does so by iterating through a list of well-known groupIds. These can be configured, but the hard-wired fall back is alwaysorg.apache.maven.plugins, I think. For each of these groupIds, maven needs the contents of the associated maven-metadata.xml file. Within this file, it looks for a <plugins> which in turn contains the prefix-to-plugin mappings.

Now, if maven thinks, that the version of that metadata within your local cache is “up-to-date”, it will not query the remote repository. You can check this in your local repo, for me, it’s in ~/.m2/repository/org/apache/maven/plugins. There you should see one or more files named maven-metadata-<some repository id>.xml, which is the cached version for one particular remote repository. If you delete those files (I went ahead and wiped the whole directory, actually), you force maven to download all the metadata again the next time it needs to lookup a plugin prefix. And this is what I did to trigger the problem: The metadata file generated by reposilite simply does not contain the required information.

I think that during the generating of metadata file we can just verify by artifact name if it may be a plugin and just move it to the plugins section.

Here, you lost me, I’m afraid. We don’t have an artifact name to begin with, or do we?

I just had another look at the MetadataService, trying to understand how it works. To tell the truth, it’s probably much to late , and I should get some sleep first 😃 But I was wondering: is the metadata only generated from the artifacts that are actually locally stored/cached?

ldegen on May 7, 2021