Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error

this should be fixed now: can you check it?
having a testcase of a pom successfully building but not downloading its parent would help too, to be sure such a regression don't arrive in the future

With 2.0.9 this bug still exists.

Using custom repos in settings.xml the repositories resolution of the parent pom will omit repos from settings.xml and always use the first mirror or http://repo1.maven.org/maven2.

From what I can see this issue still exists in trunk since the code hasn't changed. In Pom.checkParentPom a Model is created from the pom.xml but the model.getRepositories() returned is incorrect.

can you attach a testcase, please?

Sorry I was out of town.

I will try to come up with something you might be able to use, because of the need of repos in settings.xml.

I imagine creating a testcase will require some work: thank you for your help.

Well, here we have a case where the pom would use a parent which is not in the "common" repos.
I define a repository in the settings.xml.

Using maven 2.0.9 this works.

Using the ant task 2.0.9 it doesn't as it ignores the settings.xml repository:

[pom] Error downloading parent pom org.codehaus.plexus:plexus::1.0.12-SNAPSHOT: Missing:
[pom] ----------
[pom] 1) org.codehaus.plexus:plexus:pom:1.0.12-SNAPSHOT
[pom] Path to dependency:
[pom] 1) unspecified:unspecified:jar:0.0
[pom] 2) org.codehaus.plexus:plexus:pom:1.0.12-SNAPSHOT
[pom]
[pom] ----------
[pom] 1 required artifact is missing.
[pom]
[pom] for artifact:
[pom] unspecified:unspecified:jar:0.0
[pom]
[pom] from the specified remote repositories:
[pom] central (http://repo1.maven.org/maven2)

Is this sufficient for reopening this bug?

In this case it's a warning but when important info is contained in parent like properties the build will fail.

This case is just to show that the parent pom is not used.

As I stated, it differ from maven behavior.

The problem seems to be the model constructed with the XML (pom) reader which doesn't take into account settings.xml. I patched our version here by constructing a Pom object with the model info and it now works great.

However do not think it's the proper way of fixing this. So I am not going to submit the patch. Since I have limited time to put on this. But the question is why use a different way of dealing with poms when it's a parent? I mean there's a Pom class but here we use another type which in principle should represent the same thing...

ok, you finished convincing me,and you gave me sufficient testcase to work on this issue again: please reopen...

the question is why use a different way of dealing with poms when it's a parent?

this is a workaround that solved some issues with parent pom
But it seems to cause other problems in other conditions.
I'll have to work on it once more...

Hopefully this gets fixed in 2.1.0?

Is there an official reopen or is it fixed in trunk right now?

I reopen the issue since the "checkParentPom()" workaround doesn't work in the case reported now.
I don't understand why Maven manages the case and not Maven Ant Task: AFAIK, it's same code.
Need to investigate deeper...

I am having the same problem. I believe the difference between maven and the ant tasks is that maven starts with the parent pom first and then traverses through the child branches. ASSUMPTION [ The ant tasks have no idea where the parent pom resides and therefore is forced to use the repo. If the parent pom hasn't been installed, it fails. What I think we need is a way to specify or load a parent pom before processing. ] I am trying to solve this now by pre-installing the parent pom or pre-loading. Will let you know if I find a decent work-around.

As an easy work-around, if you load the parent pom with the module/child pom using the <pom> task, you will get the warning, but the build will use the parent pom. Might want to be able to specify it in the task instead of using the task twice.

In my case I have non-standard local repository specified in my settings.xml file; I was able to correct the issue by specifying a value for the settingsFile attribute on the <pom> task. This option doesn't appear in the task documentation (Pom extends from AbstractArtifactTask), but it allows the task to reference the correct local repository location.

I think I have a problem that is related to this issue as well. If I have a pom that lists a parent pom using <relativePath> in the pom.xml, it seems that it ignores the relativePath and only looks in the local repository for the parent pom. I have gotten around this problem in my build script by doing this:

<artifact:pom file="${path-to-parent-pom-as-defined-in-relativePath}" id="parentPom" />
<artifact:install pomrefid="parentPom" />

But it doesn't seem right that I should be required to do this.

<project name="test" xmlns:artifact="org.apache.maven.artifact.ant">
	<!-- These two lines shouldn't be necessary -->
	<artifact:pom file="parent-pom.xml" id="parent" />
	<artifact:install pomrefid="parent" />
	
	<!-- This line fails unless the previous two lines are there -->
    <artifact:pom file="pom.xml" id="pom"/>
</project>

<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.gfs.test</groupId>
	<artifactId>main</artifactId>
	<parent>
	   <groupId>com.gfs.test</groupId>
	   <artifactId>parent</artifactId>
	   <version>1.0.0</version>
	   <relativePath>./parent-pom.xml</relativePath>
	</parent>
	<packaging>jar</packaging>
	<version>1.0.0</version>
</project>

<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.gfs.test</groupId>
	<artifactId>parent</artifactId>
	<packaging>pom</packaging>
	<version>1.0.0</version>
</project>

I made my own modifications so that it works.

It seems to work pretty well, I am at home right and my source is at my office,
I will attach the source tomorrow. In the mean time you can use the attached fixed jar.

Pino, can you attach the sources/patch for your fix?

I spent some time looking into this issue, and it appears that the problem is caused by a disconnect between the repositories defined in the ant tasks

<pom id="test">
  <remoteRepository url="http://myhouse.com"/>
</pom>

And the repositories defined using the normal maven way through profiles in the settings or in the pom, etc.

Repositories from the settings.xml or pom.xml are picked up normally by the MavenProjectBuilder when the pom project is build. Unfortunately the MavenProjectBuilder doesn't have a simple way to pass extra repositories when building the project. So I believe that's why we currently have the extra step of trying to resolve the parent pom (using the ant defined repositories) before we build the whole pom project.

Unfortunately that extra resolution step for the parent pom only uses the repositories defined in the ant tag. So you get warnings if the parent pom is located in a repository that's defined in settings.xml or pom.xml.

I believe the correct solution to this is to dynamically create an active profile that contains all the repositories defined in the ant tag, and then add that profile to the profile manager to be used by the MavenProjectBuilder. This way all the repositories (defined in maven or in ant) will be available when the pom project is built.

This has been changed (and hopefully fixed) in r771425

I believe this issue is resolve now. If similar problems still occur please create a new issue or reopen this one.

I still get this problem with 2.0.10.

UILD FAILED
/Users/benson/x/trunk/rlp/utilities/source/java/maven-artifact.xml:16: Unable to initialize POM pom.xml: Cannot find parent: com.basistech:common-parent for project: com.basistech:utilities:jar:7.0-SNAPSHOT for project com.basistech:utilities:jar:7.0-SNAPSHOT

I have to install tasks in a row: one for the parent, and one for the 'utilities' artifact that uses it. I get the error above.

I can't reopen because I'm not the original author.

Benson, can you open a new issue and attach a sample project that reproduces the problem? This issue covers several related problems, so I would prefer a new Jira issue vs. reopening this one.