Uploaded image for project: 'Ivy'
  1. Ivy
  2. IVY-933

Maven2 parser checks version in the POM with the expected version

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-RC1
    • Fix Version/s: None
    • Component/s: Maven Compatibility
    • Labels:
      None

      Description

      When Ivy downloads a POM, it checks if the version inside the POM is the same as the expected version.
      Maven2 doesn't check this.

      For instance: http://repo1.maven.org/maven2/jdo/jdo/2.0-beta/jdo-2.0-beta.pom
      Ivy will fail resolving this dependency, maven2 doesn't fail.

      Even more: maven2 will download the 2.0-beta jar, but inside the POM the version is 1.0.1, so it seems that maven2 uses the version from the URL instead of the version from the POM.

        Activity

        Hide
        xavier Xavier Hanin added a comment -

        Actually this behaviour is supported in Ivy, but it isn't the default : you just need to set checkconsistency="false" on the resolver. Maybe we should make checkconsistency false by default on ibiblio resolver?

        Show
        xavier Xavier Hanin added a comment - Actually this behaviour is supported in Ivy, but it isn't the default : you just need to set checkconsistency="false" on the resolver. Maybe we should make checkconsistency false by default on ibiblio resolver?
        Hide
        maartenc Maarten Coene added a comment -

        I don't think that will be enough, if the version is different, maven2 will use the version definied in the filename, not in the POM. I think Ivy will always use the version from the POM?

        And maybe we should see what maven does when groupId and artifactId is also inconsistent in this case?

        Show
        maartenc Maarten Coene added a comment - I don't think that will be enough, if the version is different, maven2 will use the version definied in the filename, not in the POM. I think Ivy will always use the version from the POM? And maybe we should see what maven does when groupId and artifactId is also inconsistent in this case?
        Hide
        xavier Xavier Hanin added a comment -

        I think Ivy trust the dependency declaration, and not the pom information, so it behaves the same way as maven. And I think inconsistent groupId, artifactId and revision are supported. I may be wrong though, it's only from the top of my head.

        Show
        xavier Xavier Hanin added a comment - I think Ivy trust the dependency declaration, and not the pom information, so it behaves the same way as maven. And I think inconsistent groupId, artifactId and revision are supported. I may be wrong though, it's only from the top of my head.
        Hide
        maartenc Maarten Coene added a comment -

        ok, I'll check which version Ivy will take...
        If it does trust the dependency declaration, I'll set the checkconsistency property to "false" by default on the ibiblio resolver as you suggested. Ok?

        Show
        maartenc Maarten Coene added a comment - ok, I'll check which version Ivy will take... If it does trust the dependency declaration, I'll set the checkconsistency property to "false" by default on the ibiblio resolver as you suggested. Ok?
        Hide
        maartenc Maarten Coene added a comment -

        I just did a test and it seems that Ivy is taking the version from the pom, not from the dependency declaration

        Show
        maartenc Maarten Coene added a comment - I just did a test and it seems that Ivy is taking the version from the pom, not from the dependency declaration
        Hide
        jamespoli James Poli added a comment -

        Our team has noticed "bad revision" ERROR doesn't cause a build failure if the module is found later in the resolve. This to us is a hidden ERROR only found when we interrogated the build log. Could an attribute be added to configure this type of error to cause a build failure?

        Thanks in advance, Jim

        Show
        jamespoli James Poli added a comment - Our team has noticed "bad revision" ERROR doesn't cause a build failure if the module is found later in the resolve. This to us is a hidden ERROR only found when we interrogated the build log. Could an attribute be added to configure this type of error to cause a build failure? Thanks in advance, Jim
        Hide
        maartenc Maarten Coene added a comment -

        Jim, could you give an example of this behaviour?
        And are you sure that you specified checkconsistency="true" on your resolver?

        Maarten

        Show
        maartenc Maarten Coene added a comment - Jim, could you give an example of this behaviour? And are you sure that you specified checkconsistency="true" on your resolver? Maarten

          People

          • Assignee:
            Unassigned
            Reporter:
            maartenc Maarten Coene
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development