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
          Georges-Etienne Legendre added a comment - - edited

          Also,

          The release plugin doesn't like empty relativePath. It still works, but we get strange exceptions in the log:

          [INFO] ------------------------------------------------------------------------
          [INFO] Building ABC Parent POM 1.0.0-SNAPSHOT
          [INFO] ------------------------------------------------------------------------
          [INFO]
          [INFO] maven-release-plugin:2.0:prepare (default-cli) @ xyz-parent
          ...
          [INFO] Transforming 'ABC Parent POM'...
          org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Missing:
          ----------
          1) com.xyz.maven.pom:xyz-parent:pom:RELEASE
          ----------
          1 required artifact is missing.

          for artifact:
          com.xyz.maven.pom:xyz-parent:pom:RELEASE

          from the specified remote repositories:
          nexus (https://xyz/devel/nexus/content/groups/public, releases=true, snapshots=false)
          for project com.xyz.maven.pom:xyz-parent:pom:RELEASE
          at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237)
          at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:204)
          at org.apache.maven.project.MavenProject.getParent(MavenProject.java:351)
          at org.apache.maven.project.MavenProject.hasParent(MavenProject.java:370)
          at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewriteParent(AbstractRewritePomsPhase.java:393)
          at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:249)
          at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:208)
          at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:114)
          at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:780)
          at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
          at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
          at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
          at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
          at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
          at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
          at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
          at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
          at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
          at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
          at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
          at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
          Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
          ----------
          1) com.xyz.maven.pom:xyz-parent:pom:RELEASE
          ----------
          1 required artifact is missing.

          for artifact:
          com.xyz.maven.pom:xyz-parent:pom:RELEASE

          from the specified remote repositories:
          nexus (https://xyz/devel/nexus/content/groups/public, releases=true, snapshots=false)

          at org.apache.maven.artifact.resolver.DefaultResolutionErrorHandler.throwErrors(DefaultResolutionErrorHandler.java:71)
          at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:233)
          ... 34 more
          [INFO] Not removing release POMs
          [INFO] Full run would be checking in 1 files with message: '[maven-release-plugin] prepare for next development iteration'
          [INFO] Release preparation simulation complete.
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD SUCCESS
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 7.891s
          [INFO] Finished at: Wed May 26 08:04:02 EDT 2010
          [INFO] Final Memory: 4M/8M
          [INFO] ------------------------------------------------------------------------

          Show
          Georges-Etienne Legendre added a comment - - edited Also, The release plugin doesn't like empty relativePath. It still works, but we get strange exceptions in the log: [INFO] ------------------------------------------------------------------------ [INFO] Building ABC Parent POM 1.0.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] maven-release-plugin:2.0:prepare (default-cli) @ xyz-parent ... [INFO] Transforming 'ABC Parent POM'... org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Missing: ---------- 1) com.xyz.maven.pom:xyz-parent:pom:RELEASE ---------- 1 required artifact is missing. for artifact: com.xyz.maven.pom:xyz-parent:pom:RELEASE from the specified remote repositories: nexus ( https://xyz/devel/nexus/content/groups/public , releases=true, snapshots=false) for project com.xyz.maven.pom:xyz-parent:pom:RELEASE at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:204) at org.apache.maven.project.MavenProject.getParent(MavenProject.java:351) at org.apache.maven.project.MavenProject.hasParent(MavenProject.java:370) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewriteParent(AbstractRewritePomsPhase.java:393) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:249) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:208) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:114) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:780) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103) at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160) at org.apache.maven.cli.MavenCli.main(MavenCli.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: ---------- 1) com.xyz.maven.pom:xyz-parent:pom:RELEASE ---------- 1 required artifact is missing. for artifact: com.xyz.maven.pom:xyz-parent:pom:RELEASE from the specified remote repositories: nexus ( https://xyz/devel/nexus/content/groups/public , releases=true, snapshots=false) at org.apache.maven.artifact.resolver.DefaultResolutionErrorHandler.throwErrors(DefaultResolutionErrorHandler.java:71) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:233) ... 34 more [INFO] Not removing release POMs [INFO] Full run would be checking in 1 files with message: ' [maven-release-plugin] prepare for next development iteration' [INFO] Release preparation simulation complete. [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 7.891s [INFO] Finished at: Wed May 26 08:04:02 EDT 2010 [INFO] Final Memory: 4M/8M [INFO] ------------------------------------------------------------------------
          Hide
          Stan Devitt added a comment -

          In our standard project structure we have a large number of projects which inherit their plugin configuration from a single centralized parent - loaded from the repository. Separately the projects have one or more aggregator poms which resides in the directory directly above.

          In this setup, we cannot use <relativePath>, but maven 3 beta complains because the aggregator it finds is not the parent.

          It is actually important to separate the roles of parent and aggregator - but the current design confuses them.

          Show
          Stan Devitt added a comment - In our standard project structure we have a large number of projects which inherit their plugin configuration from a single centralized parent - loaded from the repository. Separately the projects have one or more aggregator poms which resides in the directory directly above. In this setup, we cannot use <relativePath>, but maven 3 beta complains because the aggregator it finds is not the parent. It is actually important to separate the roles of parent and aggregator - but the current design confuses them.
          Hide
          Andrew Phillips added a comment -

          I ran into this problem setting up a Maven project to be hosted by the de-facto "Maven people" themselves on the Nexus OSS server [1], and got the following answer from Juven Xu at Sonatype:

          > From: Juven Xu <...@sonatype.com>
          > Subject: Re: Inheriting from oss-parent for Nexus releases causes warning?
          >
          > IMO Maven should not log this warning if no relativePath is specified. The
          > project structure has no problem, it's a problem of Maven.

          So I guess that should count as another +1 vote

          [1] https://docs.sonatype.org/display/repository/sonatype+oss+maven+repository+usage+guide#SonatypeOSSMavenRepositoryUsageGuide-7.POMandsettingsconfig

          Show
          Andrew Phillips added a comment - I ran into this problem setting up a Maven project to be hosted by the de-facto "Maven people" themselves on the Nexus OSS server [1] , and got the following answer from Juven Xu at Sonatype: > From: Juven Xu <...@sonatype.com> > Subject: Re: Inheriting from oss-parent for Nexus releases causes warning? > > IMO Maven should not log this warning if no relativePath is specified. The > project structure has no problem, it's a problem of Maven. So I guess that should count as another +1 vote [1] https://docs.sonatype.org/display/repository/sonatype+oss+maven+repository+usage+guide#SonatypeOSSMavenRepositoryUsageGuide-7.POMandsettingsconfig
          Hide
          Stan Devitt added a comment -

          Current design of 3.0 betas assumes the pom of the directory above is a parent. Good design separates the role of parent and aggregation and it makes sense for the aggregator to be in the directory above, and for the parent to be a stable configuration that come from the repository.

          It would be very nice for this to be sorted out before the release of Maven 3.0.

          Show
          Stan Devitt added a comment - Current design of 3.0 betas assumes the pom of the directory above is a parent. Good design separates the role of parent and aggregation and it makes sense for the aggregator to be in the directory above, and for the parent to be a stable configuration that come from the repository. It would be very nice for this to be sorted out before the release of Maven 3.0.
          Hide
          Paul Gier added a comment -

          As a workaround, to avoid the warning the relativePath can be set to blank.

          <parent>
            <groupId>org.acme</groupId>
            <artifactId>foo</artifactId>
            <version>1.0</version>
            <relativePath></relativePath>
          </parent>
          
          Show
          Paul Gier added a comment - As a workaround, to avoid the warning the relativePath can be set to blank. <parent> <groupId>org.acme</groupId> <artifactId>foo</artifactId> <version>1.0</version> <relativePath></relativePath> </parent>
          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:
              36 Vote for this issue
              Watchers:
              40 Start watching this issue

              Dates

              • Created:
                Updated: