Uploaded image for project: 'Maven Archetype'
  1. Maven Archetype
  2. ARCHETYPE-358

Following mirror configuration from settings.xml

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 3.0.0
    • Component/s: Generator, Plugin
    • Labels:
      None

      Description

      It looks like the current snapshot of the plugin does not follow the mirror configuration from my settings.xml when I do mvn archetype:generate. I would expect it to grab the catalog from http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml instead of the central one.

      1. patch.txt
        3 kB
        Chris Feldhacker

        Issue Links

          Activity

          Hide
          feldhacker Chris Feldhacker added a comment - - edited

          We're experiencing this problem, too.
          We have our own Sonatype Nexus repository setup behind the firewall, which is defined in the mirrors section of the settings.xml. Standard Maven operations work fine, no proxy settings needed in the settings.xml file.

          When executing mvn archetype:generate, however, the error "Connection to http://repo1.maven.org refused" is given. (Similar symptoms to ARCHETYPE-202, but different cause.) The archetype plugin should NOT be trying to connect to this URL directly – instead, it should be using the mirror we have defined.

          Show
          feldhacker Chris Feldhacker added a comment - - edited We're experiencing this problem, too. We have our own Sonatype Nexus repository setup behind the firewall, which is defined in the mirrors section of the settings.xml. Standard Maven operations work fine, no proxy settings needed in the settings.xml file. When executing mvn archetype:generate , however, the error "Connection to http://repo1.maven.org refused" is given. (Similar symptoms to ARCHETYPE-202 , but different cause.) The archetype plugin should NOT be trying to connect to this URL directly – instead, it should be using the mirror we have defined.
          Hide
          feldhacker Chris Feldhacker added a comment -

          Based on my limited digging and Maven plugin knowledge:

          I think fixing this is tough (well, it involves a difficult decision) because there appears to be a design mismatch in how the archetype plugin operates and how Maven itself operates. Maven operates based on a LIST of remote repositories: the user may or may not use central, and all servers are filtered through the mirrors list to arrive at a final list of remote repositories. However, in the final remote repository list, knowledge of which repository maps to central (if any) is lost.

          The archetype plugin is hard-coded to look at exactly one remote repository, central. There's no good way to resolve or map central to some other repository (not without some bad hacking) – exactly which remote repository from the list should map to central is unknown.

          So I think the ultimate question is: Should the archetype plugin really be hard-coded to look directly at one repository, central? Why not utilize the list of remote repositories that core Maven already provides (already filtered through the mirrors), searching each one by one?

          Show
          feldhacker Chris Feldhacker added a comment - Based on my limited digging and Maven plugin knowledge: I think fixing this is tough (well, it involves a difficult decision) because there appears to be a design mismatch in how the archetype plugin operates and how Maven itself operates. Maven operates based on a LIST of remote repositories: the user may or may not use central, and all servers are filtered through the mirrors list to arrive at a final list of remote repositories. However, in the final remote repository list, knowledge of which repository maps to central (if any) is lost. The archetype plugin is hard-coded to look at exactly one remote repository, central. There's no good way to resolve or map central to some other repository (not without some bad hacking) – exactly which remote repository from the list should map to central is unknown. So I think the ultimate question is: Should the archetype plugin really be hard-coded to look directly at one repository, central? Why not utilize the list of remote repositories that core Maven already provides (already filtered through the mirrors), searching each one by one?
          Hide
          feldhacker Chris Feldhacker added a comment -

          Attached is a patch for the DefaultArchetypeSelector class.
          A new dependency on "org.apache.maven:maven-compat:3.0.4" is needed in order to reuse existing Mirror processing logic.
          The patch trades a hard-coded URL to central (which is bad) with a hard-coded server id of "central" (which is also bad). Not an ideal solution, but certainly no worse off than today...

          Unfortunately, the getMirrors() method of the existing ArchetypeGenerationRequest argument returns an empty list of Mirrors and I don't know why or what the proper way would be to resolve it. Perhaps if somebody could jump in and solve the other half of this puzzle, we could get a workable solution...

          Show
          feldhacker Chris Feldhacker added a comment - Attached is a patch for the DefaultArchetypeSelector class. A new dependency on "org.apache.maven:maven-compat:3.0.4" is needed in order to reuse existing Mirror processing logic. The patch trades a hard-coded URL to central (which is bad) with a hard-coded server id of "central" (which is also bad). Not an ideal solution, but certainly no worse off than today... Unfortunately, the getMirrors() method of the existing ArchetypeGenerationRequest argument returns an empty list of Mirrors and I don't know why or what the proper way would be to resolve it. Perhaps if somebody could jump in and solve the other half of this puzzle, we could get a workable solution...
          Hide
          afloom Anders Hammar added a comment -

          I agree. Trading the hardcoded url for the repo/server id is good. And then use the standard Maven logic for using the correct mirror.

          Show
          afloom Anders Hammar added a comment - I agree. Trading the hardcoded url for the repo/server id is good. And then use the standard Maven logic for using the correct mirror.
          Hide
          afloom Anders Hammar added a comment -

          As a note, there's A LOT of docs to update if we implement this change. It is stated in several pages that the central repo url is used by default, which should be changed to state that the url defined by the (magic) repo id 'central' is used.

          Show
          afloom Anders Hammar added a comment - As a note, there's A LOT of docs to update if we implement this change. It is stated in several pages that the central repo url is used by default, which should be changed to state that the url defined by the (magic) repo id 'central' is used.
          Hide
          afloom Anders Hammar added a comment -

          I've created ARCHETYPE-427 which is about changing the current behavior with one hard-coded repo url.

          Show
          afloom Anders Hammar added a comment - I've created ARCHETYPE-427 which is about changing the current behavior with one hard-coded repo url.
          Hide
          gjoseph Grégory Joseph added a comment -

          Now seeing a similar issue - which may or may not be related.

          mvn archetype:generate -DarchetypeCatalog=http://nexus.magnolia-cms.com/content/groups/enterprise

          The first time I execute the command, I can access the catalog - which is hinting that my settings.xml are taken into account. The second time, I do get a permission issue.

          If I remove my settings.xml, the first time fails, somehow confirming they're used - once, but not twice ? I have NO IDEA what the difference between the first and the second run is, since I don't have cd into the newly created project, so there is NO pom.xml to interfere with mvn right there ... Puzzling !

          Show
          gjoseph Grégory Joseph added a comment - Now seeing a similar issue - which may or may not be related. mvn archetype:generate -DarchetypeCatalog= http://nexus.magnolia-cms.com/content/groups/enterprise The first time I execute the command, I can access the catalog - which is hinting that my settings.xml are taken into account. The second time, I do get a permission issue. If I remove my settings.xml, the first time fails, somehow confirming they're used - once, but not twice ? I have NO IDEA what the difference between the first and the second run is, since I don't have cd into the newly created project, so there is NO pom.xml to interfere with mvn right there ... Puzzling !
          Hide
          gjoseph Grégory Joseph added a comment -

          @anders,

          As a note, there's A LOT of docs to update if we implement this change. It is stated in several pages that the central repo url is used by default, which should be changed to state that the url defined by the (magic) repo id 'central' is used.

          That's the case for all of Maven, though, not specific to the archetype plugin. What's specific to the archetype plugin however, is that it's not consistent with the rest of Maven and doesn't respect the mirrors mandated by settings.xml. (in fact, mirrorOf:* should be enough to reproduce this error, whether or not you override the magic repo id.

          Show
          gjoseph Grégory Joseph added a comment - @anders, As a note, there's A LOT of docs to update if we implement this change. It is stated in several pages that the central repo url is used by default, which should be changed to state that the url defined by the (magic) repo id 'central' is used. That's the case for all of Maven, though, not specific to the archetype plugin. What's specific to the archetype plugin however, is that it's not consistent with the rest of Maven and doesn't respect the mirrors mandated by settings.xml. (in fact, mirrorOf:* should be enough to reproduce this error, whether or not you override the magic repo id.
          Hide
          rfscholte Robert Scholte added a comment -

          Fixed in cc7f9bc4354d7411273ceecdcb46988905c99c16
          Thanks for the patch, it was a good start for me. I've placed the logic in another class, especially now that we require Maven3

          Show
          rfscholte Robert Scholte added a comment - Fixed in cc7f9bc4354d7411273ceecdcb46988905c99c16 Thanks for the patch, it was a good start for me. I've placed the logic in another class, especially now that we require Maven3
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Jenkins build maven-archetype-m3 #252 (See https://builds.apache.org/job/maven-archetype-m3/252/)
          ARCHETYPE-358 Following mirror configuration from settings.xml (rfscholte: rev cc7f9bc4354d7411273ceecdcb46988905c99c16)

          • (edit) archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java
          • (edit) archetype-common/src/test/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSourceTest.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Jenkins build maven-archetype-m3 #252 (See https://builds.apache.org/job/maven-archetype-m3/252/ ) ARCHETYPE-358 Following mirror configuration from settings.xml (rfscholte: rev cc7f9bc4354d7411273ceecdcb46988905c99c16) (edit) archetype-common/src/main/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSource.java (edit) archetype-common/src/test/java/org/apache/maven/archetype/source/RemoteCatalogArchetypeDataSourceTest.java
          Hide
          afloom Anders Hammar added a comment -

          Robert Scholte No docs to update? Grégory says there are a lot of them to change. Should be done as well before closing IMO.

          Show
          afloom Anders Hammar added a comment - Robert Scholte No docs to update? Grégory says there are a lot of them to change. Should be done as well before closing IMO.
          Hide
          rfscholte Robert Scholte added a comment -

          ARCHETYPE-438 contains several documentation updates, can't find any docs related to mirrors.

          Show
          rfscholte Robert Scholte added a comment - ARCHETYPE-438 contains several documentation updates, can't find any docs related to mirrors.

            People

            • Assignee:
              rfscholte Robert Scholte
              Reporter:
              gjoseph Grégory Joseph
            • Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development