Maven
  1. Maven
  2. MNG-2408

Improve handling of "no plugin version found" error after intermittent errors

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 2.0.5
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      If you follow the instructions at http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20make%20my%20first%20Maven%20project? to use the archetype plugin to create a new project skeleton, the suggested command line fails as below.

      It seems there is a typo of some kind in the suggested command line, I am not familiar enough with maven 2 to know for sure.

      Graham-Leggetts-Computer:~/src/standard/alchemy/maven minfrin$ mvn archetype:create -DgroupId=za.co.standardbank.alchemy -DartifactId=alchemy-trader
      [INFO] Scanning for projects...
      [INFO] Searching repository for plugin with prefix: 'archetype'.
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exist or no valid version could be found
      [INFO] ------------------------------------------------------------------------
      [INFO] For more information, run Maven with the -e switch
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Tue Jun 27 09:43:14 SAST 2006
      [INFO] Final Memory: 1M/2M
      [INFO] ------------------------------------------------------------------------

        Issue Links

          Activity

          Hide
          John Casey added a comment -

          Resolved in trunk (2.1-snapshot), and 2.0.5-snapshot merge should be complete shortly.

          I added code to the update method in AbstractRepositoryMetadata to avoid writing the metadata to the local repo if the main version was either RELEASE or LATEST, since these are only meta-versions, and should never exist in the repo as main versions. Also added a unit test to maven-artifact-manager to check for this.

          Show
          John Casey added a comment - Resolved in trunk (2.1-snapshot), and 2.0.5-snapshot merge should be complete shortly. I added code to the update method in AbstractRepositoryMetadata to avoid writing the metadata to the local repo if the main version was either RELEASE or LATEST, since these are only meta-versions, and should never exist in the repo as main versions. Also added a unit test to maven-artifact-manager to check for this.
          Hide
          Brad Cozine added a comment -

          Was having the issue also. Emptied local repo and removed that "Australlian" (example) mirror from my settings.xml. Did the trick.

          Show
          Brad Cozine added a comment - Was having the issue also. Emptied local repo and removed that "Australlian" (example) mirror from my settings.xml. Did the trick.
          Hide
          John Casey added a comment -

          It seems that this is becoming a more common issue. From what I can tell, either the metadata download is failing (network problem), or else the file itself doesn't exist on the server. In either case, Maven is gleefully writing a new metadata file that contains 'LATEST' for the main <version/>, which should never happen.

          In 2.1, we should look at separating the meta-versions like RELEASE and LATEST from real versions, to avoid the need to correct for this sort of situation. For now, it might be a good idea to refrain from writing a dummy metadata file in the local repository when representing a remotely retrieved piece of metadata...will look into this more later.

          As a workaround

          You should be able to traverse in your local repository to the plugin's artifactId folder (org/apache/maven/plugins/maven-archetype-plugin in this example), and remove maven-metadata-*.xml. When you re-run the build, it should restore these metadata files from the repositories, and should resume normal functioning.

          Show
          John Casey added a comment - It seems that this is becoming a more common issue. From what I can tell, either the metadata download is failing (network problem), or else the file itself doesn't exist on the server. In either case, Maven is gleefully writing a new metadata file that contains 'LATEST' for the main <version/>, which should never happen. In 2.1, we should look at separating the meta-versions like RELEASE and LATEST from real versions, to avoid the need to correct for this sort of situation. For now, it might be a good idea to refrain from writing a dummy metadata file in the local repository when representing a remotely retrieved piece of metadata...will look into this more later. As a workaround You should be able to traverse in your local repository to the plugin's artifactId folder (org/apache/maven/plugins/maven-archetype-plugin in this example), and remove maven-metadata-*.xml. When you re-run the build, it should restore these metadata files from the repositories, and should resume normal functioning.
          Hide
          Brett Porter added a comment -

          ok, usually it's a configuration error (you have a proxy that isn't configured).

          Since it's not the case, it must have been an intermittent issue with ibiblio, which caused a metadata error. This is a known issue (probably filed elsewhere).

          I'll assign this to 2.0.5 for now, but we should try and find the original issue.

          Show
          Brett Porter added a comment - ok, usually it's a configuration error (you have a proxy that isn't configured). Since it's not the case, it must have been an intermittent issue with ibiblio, which caused a metadata error. This is a known issue (probably filed elsewhere). I'll assign this to 2.0.5 for now, but we should try and find the original issue.
          Hide
          Graham Leggett added a comment -

          How on earth is this a configuration issue? The maven install is brand new, there is no configuration at all.

          The new user does not have a priori knowledge that they have to run maven with the -U switch. Why would they? Maven has always updated itself automatically, why should it stop now?

          Do a Google search for the above error, and you get person after person asking the same question over and over again.

          All it takes is a single extra line of documentation indicating to the user that the -U switch may be required on new installations.

          Please take feedback from new users seriously. I know it is difficult from the point of view of a developer to see maven as the new user sees it. When a new user points out something isn't clear, then change it so it is. Maven is supposed to make the developer's life easier, not harder.

          Show
          Graham Leggett added a comment - How on earth is this a configuration issue? The maven install is brand new, there is no configuration at all. The new user does not have a priori knowledge that they have to run maven with the -U switch. Why would they? Maven has always updated itself automatically, why should it stop now? Do a Google search for the above error, and you get person after person asking the same question over and over again. All it takes is a single extra line of documentation indicating to the user that the -U switch may be required on new installations. Please take feedback from new users seriously. I know it is difficult from the point of view of a developer to see maven as the new user sees it. When a new user points out something isn't clear, then change it so it is. Maven is supposed to make the developer's life easier, not harder.
          Hide
          Brett Porter added a comment -
          Show
          Brett Porter added a comment - http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-novalidversion It's a configuration error on your end.

            People

            • Assignee:
              John Casey
              Reporter:
              Graham Leggett
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: