Maven Ant Tasks
  1. Maven Ant Tasks
  2. MANTTASKS-87

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.9
    • Fix Version/s: 2.0.10
    • Component/s: pom task
    • Labels:
      None
    • Environment:
      WindowsXP
      Ant version 1.7.0
    • Number of attachments :
      2

      Description

      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 WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to maven-ant-tasks-2.0.7.jar and still an issue with the latest maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)).

      Just to see if I had done something wrong with the pom.xml file I tried to run a Maven goal against the pom.xml file. I found that if I run "mvn clean" from this same directory (where the build.xml and pom.xml file is located), using Maven-2.0.7, I get a build successfull (it was able to find the parent pom.xml file... so this seems to be isolated to JUST the maven-ant-task not being able to find the parent pom.xml)

            • Sample of the pom.xml file ****
              <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
              <modelVersion>4.0.0</modelVersion>
              <groupId>intuit.sbconnect</groupId>
              <artifactId>sbclogin</artifactId>
              <version>1.0.3</version>
              <name>SBCLogin</name>

      <parent>
      <groupId>mygroup</groupId>
      <artifactId>CommonPOM</artifactId>
      <version>1.0.2</version>
      </parent>

      <dependencies>
      <dependency>
      <groupId>myothergroup</groupId>
      <artifactId>myartifact</artifactId>
      <version>1.0</version>
      </dependency>
      </dependencies>
      </project>

            • Line in Ant build.xml file that causes the error: ****

      <artifact:pom id="maven.project" file="pom.xml"/>

            • Error that occurs when this line is executed in ant: ****

      Error downloading parent pom: Missing:
      ----------
      1) mygroup:CommonPOM:pom:1.0.2
      Path to dependency:
      1) unspecified:unspecified:jar:0.0
      2) mygroup:CommonPOM:pom:1.0.2

      ----------
      1 required artifact is missing.

      for artifact:
      unspecified:unspecified:jar:0.0

      from the specified remote repositories:
      central (http://repo1.maven.org/maven2)

      1. CASE.tar.gz
        875 kB
        Pino Silvaggio

        Activity

        Hide
        Herve Boutemy added a comment -

        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

        Show
        Herve Boutemy added a comment - 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
        Hide
        Pino Silvaggio added a comment -

        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.

        Show
        Pino Silvaggio added a comment - 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.
        Hide
        Herve Boutemy added a comment -

        can you attach a testcase, please?

        Show
        Herve Boutemy added a comment - can you attach a testcase, please?
        Hide
        Pino Silvaggio added a comment -

        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.

        Show
        Pino Silvaggio added a comment - 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.
        Hide
        Herve Boutemy added a comment -

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

        Show
        Herve Boutemy added a comment - I imagine creating a testcase will require some work: thank you for your help.
        Hide
        Pino Silvaggio added a comment -

        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)

        Show
        Pino Silvaggio added a comment - 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 )
        Hide
        Pino Silvaggio added a comment -

        Is this sufficient for reopening this bug?

        Show
        Pino Silvaggio added a comment - Is this sufficient for reopening this bug?
        Hide
        Herve Boutemy added a comment -

        I checked the testcase: I have the same output.
        But this message is only a warning, and nothing blocks the build to go further.
        Is there an tangible impact of this message on your build, or only the message is causing some questions?

        Show
        Herve Boutemy added a comment - I checked the testcase: I have the same output. But this message is only a warning, and nothing blocks the build to go further. Is there an tangible impact of this message on your build, or only the message is causing some questions?
        Hide
        Pino Silvaggio added a comment -

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

        Show
        Pino Silvaggio added a comment - 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...
        Hide
        Herve Boutemy added a comment -

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

        Show
        Herve Boutemy added a comment - 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...
        Hide
        Pino Silvaggio added a comment -

        Hopefully this gets fixed in 2.1.0?

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

        Show
        Pino Silvaggio added a comment - Hopefully this gets fixed in 2.1.0? Is there an official reopen or is it fixed in trunk right now?
        Hide
        Herve Boutemy added a comment -

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

        Show
        Herve Boutemy added a comment - 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...
        Hide
        Charles Canning added a comment -

        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.

        Show
        Charles Canning added a comment - 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.
        Hide
        Charles Canning added a comment -

        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.

        Show
        Charles Canning added a comment - 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.
        Hide
        Jeremy Gustie added a comment -

        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.

        Show
        Jeremy Gustie added a comment - 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.
        Hide
        Bruce Brouwer added a comment - - edited

        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.

        build.xml
        <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>
        pom.xml
        <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>
        
        parent-pom.xml
        <project>
        	<modelVersion>4.0.0</modelVersion>
        	<groupId>com.gfs.test</groupId>
        	<artifactId>parent</artifactId>
        	<packaging>pom</packaging>
        	<version>1.0.0</version>
        </project>
        
        Show
        Bruce Brouwer added a comment - - edited 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. build.xml <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> pom.xml <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> parent-pom.xml <project> <modelVersion> 4.0.0 </modelVersion> <groupId> com.gfs.test </groupId> <artifactId> parent </artifactId> <packaging> pom </packaging> <version> 1.0.0 </version> </project>
        Hide
        Pino Silvaggio added a comment -

        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.

        Show
        Pino Silvaggio added a comment - 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.
        Hide
        Paul Gier added a comment -

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

        Show
        Paul Gier added a comment - Pino, can you attach the sources/patch for your fix?
        Hide
        Paul Gier added a comment -

        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

        Show
        Paul Gier added a comment - 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
        Hide
        Paul Gier added a comment -

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

        Show
        Paul Gier added a comment - I believe this issue is resolve now. If similar problems still occur please create a new issue or reopen this one.
        Hide
        Benson Margulies added a comment -

        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.

        Show
        Benson Margulies added a comment - 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.
        Hide
        Paul Gier added a comment -

        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.

        Show
        Paul Gier added a comment - 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.

          People

          • Assignee:
            Paul Gier
            Reporter:
            Jeff Campbell
          • Votes:
            5 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: