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

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] ------------------------------------------------------------------------

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.

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.

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>

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.

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.

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.

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:

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".

Another relevant recent thread from maven-users:

http://mail-archives.apache.org/mod_mbox/maven-users/201211.mbox/%3CCABbdPEaJPFahp8uAWmUYYkjKQQ3XdMWb6eeos9Qbx=h2bDPxaQ@mail.gmail.com%3E