Maven
  1. Maven
  2. MNG-4148

Apply profiles from settings.xml to POMs built from the repository

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.1.0
    • Fix Version/s: None
    • Labels:
      None
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      When we declare a profile in the settings.xml, it will never be applied to POMs loaded from the Maven repository. This means that overriding the central repository definition - for instance - cannot be done without using mirror definitions, since transitive dependencies (any dependency of a direct dependency) will skip the modified definition and use the original from the super-POM instead.

      I'm attaching a testing setup that was originally reported for MNG-3553, which exhibits this problem when dealing with scope == import. The instructions for using it are as follows:

      I installed locally a nexus server (1.3.3 Open Source) and I'm using maven 2.1.0 (I reproduced the issue with 2.0.10).
      In the releases repository of nexus you upload all artifacts given in the toUpload directory :
      
          * parent 1.0.0 pom
          * dependencies 1.0.0 pom
          * module 1.0.0 pom and jar
      
      You'll find in the root of the archive my settings. It defines to use nexus for the central repository.
      You launch a build of the project and you'll have :
      
      [INFO] Scanning for projects...
      [INFO] ------------------------------------------------------------------------
      [INFO] Building Unnamed - org.apache.maven.it.mng3553:project:jar:1.0.0-SNAPSHOT
      [INFO]    task-segment: [install]
      [INFO] ------------------------------------------------------------------------
      [INFO] [resources:resources]
      [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
      [INFO] skip non existing resourceDirectory E:\jtb\workspaces\tests\test-mng3553\project\src\main\resources
      Downloading: http://localhost:8081/nexus/content/groups/public//org/apache/maven/it/mng3553/module/1.0.0/module-1.0.0.pom
      867b downloaded  (module-1.0.0.pom)
      Downloading: http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
      [WARNING] Unable to get resource 'org.apache.maven.it.mng3553:dependencies:pom:1.0.0'
      from repository central (http://repo1.maven.org/maven2): Authorization failed: Access denied to:
        http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Failed to resolve artifact.
      GroupId: org.apache.maven.it.mng3553
      ArtifactId: dependencies
      Version: 1.0.0
      Reason: Unable to download the artifact from any repository
        org.apache.maven.it.mng3553:dependencies:pom:1.0.0
      from the specified remote repositories:
        central (http://repo1.maven.org/maven2)
      [INFO] ------------------------------------------------------------------------
      [INFO] For more information, run Maven with the -e switch
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Thu Apr 30 15:19:47 CEST 2009
      [INFO] Final Memory: 6M/254M
      [INFO] ------------------------------------------------------------------------
      
      
      You can see that the project downloads successfully the module-1.0.0 from nexus but
      it fails for depencencies which is an import. It tries to download it from the real central repository
      and not from the one I defined in my settings.
      The behavior is inconsistent...
      

        Issue Links

          Activity

          Hide
          abhishek misra added a comment -

          I just tried using $

          {settings.localRepository}

          in systemPath with Maven 3.0 Beta 3 and it still complains about absolute path. Will this be fixed with version 3?

          Show
          abhishek misra added a comment - I just tried using $ {settings.localRepository} in systemPath with Maven 3.0 Beta 3 and it still complains about absolute path. Will this be fixed with version 3?
          Hide
          Aurélien Girardeau added a comment -

          Hi all,
          My company deals with the same issue.
          I don't understand one thing : why this is only append when scope == import, not for other scope?

          regards

          Show
          Aurélien Girardeau added a comment - Hi all, My company deals with the same issue. I don't understand one thing : why this is only append when scope == import, not for other scope? regards
          Hide
          Tibor Varga added a comment -

          I read through the discussion Bratt linked to and tried to apply the concepts expressed there to the case I reported in MNG-4930, where the value to the given property was only supplied by settings.xml.

          Then I read that discussion again, as well as the original bug report here, and found that the overriding concern has been (excuse the pun) that allowing properties from settings.xml or any source external to the POMs to override properties defined in POMs may have serious, and unintended, consequences.

          Maven's current approach it to simply ignore any property coming from settings.xml even if it would not override anything but supply the only value to a property.

          In light of that, how about this: do not allow properties coming from outside the POMs to override properties defined in the POMs, only allow them to supply original values?

          Would that make sense?

          It would certainly solve my case, which in real life, actually, had to do with the systemPath of a system scope dependency that depended on a property defined in settings.xml.

          Show
          Tibor Varga added a comment - I read through the discussion Bratt linked to and tried to apply the concepts expressed there to the case I reported in MNG-4930 , where the value to the given property was only supplied by settings.xml . Then I read that discussion again, as well as the original bug report here, and found that the overriding concern has been (excuse the pun) that allowing properties from settings.xml or any source external to the POMs to override properties defined in POMs may have serious, and unintended, consequences. Maven's current approach it to simply ignore any property coming from settings.xml even if it would not override anything but supply the only value to a property. In light of that, how about this: do not allow properties coming from outside the POMs to override properties defined in the POMs, only allow them to supply original values ? Would that make sense? It would certainly solve my case, which in real life, actually, had to do with the systemPath of a system scope dependency that depended on a property defined in settings.xml .
          Hide
          Ben Tomasini added a comment -

          I have created a plugin which depends on a jar in a heavyweight application server which has a number of hard coded class path entries in the jar's manifest. Uploading all of the jar files to our internal repository is simply not practical.

          Using a systemPath in the dependency declaration of the plugin with a property to set the directory of the app server would be ideal in this case.

          Show
          Ben Tomasini added a comment - I have created a plugin which depends on a jar in a heavyweight application server which has a number of hard coded class path entries in the jar's manifest. Uploading all of the jar files to our internal repository is simply not practical. Using a systemPath in the dependency declaration of the plugin with a property to set the directory of the app server would be ideal in this case.
          Hide
          Jason van Zyl added a comment -

          I think profiles are specifically build time, with the possible exception of platform and JDK which is really more of an environment. If we are moving toward a consumption-time POM we want to avoid the processing of profiles as much as possible.

          Show
          Jason van Zyl added a comment - I think profiles are specifically build time, with the possible exception of platform and JDK which is really more of an environment. If we are moving toward a consumption-time POM we want to avoid the processing of profiles as much as possible.

            People

            • Assignee:
              John Casey
              Reporter:
              John Casey
            • Votes:
              27 Vote for this issue
              Watchers:
              28 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: