Maven
  1. Maven
  2. MNG-4687

Maven should not warn about incorrect parent path when no relativePath is specified

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.0-beta-1
    • Fix Version/s: None
    • Component/s: Logging
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      If a module pom uses a parent other than the one in the parent directory, maven logs a warning. In some cases it is necessary that a module pom has an external parent pom, and there is no way to refer to this external pom in the relativePath. If nothing is specified in the relativePath, Maven should not log the warning.

      [WARNING] 'parent.relativePath' of POM org.maven.test:relative-path-parent:0.0.1-SNAPSHOT (/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at org.maven.test:relative-path-test instead of org.apache.maven:maven-parent, please verify your project structure @ 
      

      The attached zip reproduces the warning.

        Issue Links

          Activity

          Hide
          Scott MacDonald added a comment -

          The requiremnt to add <relativePath></relativePath> to all poms who desire repo based resolution of thier parent pom is a bit painful when you have hundreds of modules.

          I would prefer automatic local resolution of parent poms residing in the direct parent dirctory if they exist. If a parent dir does not exist, resolve parent poms via repository. This allows for parent/child modules who are in the local workspaces to resolve properly, without the silliness of adding <relativePath></relativePath> to all poms that do not have parents in their immediate parent directory.

          In the case were a relativePath is specified, honor that local path.

          Incidentally, can anyone explain why I have been using maven 3.0.3 for about a month, and this relativePath warning just started today without any discernible related restructuring of poms, parent references, or thier directory structures? Very, very strange.

          Show
          Scott MacDonald added a comment - The requiremnt to add <relativePath></relativePath> to all poms who desire repo based resolution of thier parent pom is a bit painful when you have hundreds of modules. I would prefer automatic local resolution of parent poms residing in the direct parent dirctory if they exist. If a parent dir does not exist, resolve parent poms via repository. This allows for parent/child modules who are in the local workspaces to resolve properly, without the silliness of adding <relativePath></relativePath> to all poms that do not have parents in their immediate parent directory. In the case were a relativePath is specified, honor that local path. Incidentally, can anyone explain why I have been using maven 3.0.3 for about a month, and this relativePath warning just started today without any discernible related restructuring of poms, parent references, or thier directory structures? Very, very strange.
          Hide
          Laird Nelson added a comment -

          No, please do not do automatic local resolution.

          In a large project where pom.xml changes are made relatively frequently, sometimes users do not do, say, an svn update. In such a case a local build will reference what is effectively an out-of-date pom. If automatic filesystem resolution were turned on, there would be no way to force Maven to go get the pom from the repo. Unless, of course, I'm missing something.

          Show
          Laird Nelson added a comment - No, please do not do automatic local resolution. In a large project where pom.xml changes are made relatively frequently, sometimes users do not do, say, an svn update . In such a case a local build will reference what is effectively an out-of-date pom. If automatic filesystem resolution were turned on, there would be no way to force Maven to go get the pom from the repo. Unless, of course, I'm missing something.
          Hide
          David M. Karr added a comment -

          I just discovered this issue today, even though I had builds using this parent structure for a couple of weeks. To Scott's point, I only noticed it today because I normally work with the individual projects checked out separately. Today I tried building the entire set of projects from the tree, which is when I first noticed it. Perhaps that's why you didn't notice it until then.

          Another +1 for me. Stan's point about separation of aggregation and parent is relevant.

          Show
          David M. Karr added a comment - I just discovered this issue today, even though I had builds using this parent structure for a couple of weeks. To Scott's point, I only noticed it today because I normally work with the individual projects checked out separately. Today I tried building the entire set of projects from the tree, which is when I first noticed it. Perhaps that's why you didn't notice it until then. Another +1 for me. Stan's point about separation of aggregation and parent is relevant.
          Hide
          Curtis Rueden added a comment -

          I agree with Scott that automatic local resolution would be ideal. To respond to Laird's concern, without loss of generality, there are six cases for the behavior:

            no relativePath given in child POM <relativePath/> <relativePath>..</relativePath>
          POM in parent dir is the parent automatically use local POM in parent dir force lookup in repo force use of local POM in parent
          POM in parent dir is not the parent (or there is no POM there) automatically do lookup in repo force lookup in repo force use of local POM in parent (will fail)

          So to avoid the case where the parent directory contains an out-of-date version of the parent POM, you could add "<relativePath/>" to your child POMs to always force a repository lookup. Personally I think this is a less common case than having a multi-module build and desiring it to use the local version of the POM in the parent directory when present.

          This could be implemented easily by adding support for a special token (e.g., "AUTOMATIC") for the relativePath value, and changing the super POM's default value from ".." as it is now to "AUTOMATIC".

          Show
          Curtis Rueden added a comment - I agree with Scott that automatic local resolution would be ideal. To respond to Laird's concern, without loss of generality, there are six cases for the behavior:   no relativePath given in child POM <relativePath/> <relativePath>..</relativePath> POM in parent dir is the parent automatically use local POM in parent dir force lookup in repo force use of local POM in parent POM in parent dir is not the parent (or there is no POM there) automatically do lookup in repo force lookup in repo force use of local POM in parent (will fail) So to avoid the case where the parent directory contains an out-of-date version of the parent POM, you could add "<relativePath/>" to your child POMs to always force a repository lookup. Personally I think this is a less common case than having a multi-module build and desiring it to use the local version of the POM in the parent directory when present. This could be implemented easily by adding support for a special token (e.g., "AUTOMATIC") for the relativePath value, and changing the super POM's default value from ".." as it is now to "AUTOMATIC".
          Show
          Curtis Rueden added a comment - Another relevant recent thread from maven-users: http://mail-archives.apache.org/mod_mbox/maven-users/201211.mbox/%3CCABbdPEaJPFahp8uAWmUYYkjKQQ3XdMWb6eeos9Qbx=h2bDPxaQ@mail.gmail.com%3E

            People

            • Assignee:
              Unassigned
              Reporter:
              Paul Gier
            • Votes:
              35 Vote for this issue
              Watchers:
              39 Start watching this issue

              Dates

              • Created:
                Updated: