Maven
  1. Maven
  2. MNG-2289

Newer SNAPSHOT parents in the remote repository are ignored

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.0.5
    • Fix Version/s: None
    • Labels:
      None

      Description

      If a POM inherits from another one in the repository with a SNAPSHOT version, it will only look into the local repository for it, but not in the remote repositories.
      E.g. if a POM has following parent:...
      <parent>
      <groupId>pom.maven</groupId>
      <artifactId>super</artifactId>
      <version>SNAPSHOT</version>
      </parent>
      ...

      it will not find a newer version of "pom.maven:super:SNAPSHOT" in a remote repository.

      1. example.zip
        49 kB
        Roger Butenuth
      2. mng2289.zip
        5 kB
        Joerg Schaible

        Issue Links

          Activity

          Hide
          Roger Butenuth added a comment -

          The problem seems to be more general for me:

          We use maven 2 to build a large project consisting of several modules.
          Dependencies between modules are handled by the maven dependency
          mechanism. During development, we want to use the SNAPSHOT feature
          because we don't want to have an inflation of version numbers.

          The problem: For me it looks like snapshots are never updated in the
          local repository.

          To track this down, I have done the following test:

          1. Deploy "interface" to our central repository 2. Compile "client"
          (which depends on "interface")
          pom, jar and metadata are downloaded into local repository.
          3. Increased version number and timestamp in the file
          1.0-SNAPSHOT/maven-metadata.xml, recomputed checksums.
          4. Run "mvn -U clean compile" on module "client".
          This results in the following log:

          [INFO] Scanning for projects...
          [INFO]
          --------------------------------------------------------------
          --------------
          [INFO] Building Client for the great calculator
          [INFO] task-segment: [clean, compile]
          [INFO]
          --------------------------------------------------------------
          --------------
          [INFO] artifact org.apache.maven.plugins:maven-clean-plugin:
          checking for updates from central
          [INFO] artifact org.apache.maven.plugins:maven-source-plugin:
          checking for updates from central
          [INFO] artifact
          org.apache.maven.plugins:maven-surefire-plugin: checking for updates
          from central [INFO] [clean:clean] [INFO] Deleting directory
          c:\example\client\target [INFO] Deleting directory
          c:\example\client\target\classes [INFO] Deleting directory
          c:\example\client\target\test-classes
          [INFO] artifact org.apache.maven.plugins:maven-resources-plugin:
          checking for updates from central [INFO] artifact
          org.apache.maven.plugins:maven-compiler-plugin: checking for updates
          from central [INFO] [source-download:download-sources

          {execution: default}

          ]

          -----> [INFO] snapshot
          de.sdm.calculator:interface:1.0-SNAPSHOT: checking for updates from
          central <------

          [INFO] [resources:resources]
          [INFO] Using default encoding to copy filtered resources. [INFO]
          snapshot de.sdm.calculator:calculator-all:1.0-SNAPSHOT: checking for
          updates from central [INFO] [compiler:compile] Compiling 1 source file
          to c:\example\client\target\classes [INFO]
          --------------------------------------------------------------
          ----------
          [INFO] BUILD SUCCESSFUL

          As you can see in the marked line, the check for updates is done.
          Looking into ~/.m2/repository I can see even the new
          maven-metadata-central.xml (new timestamp, new content), but the jar
          is NOT updated from the server.

          Is this intendented behaviour?

          I can solve the problem by setting
          <uniqueVersion>true</uniqueVersion> master pom of the project, but
          this clobberes the local repositories of all users and the central
          repository with lots of old versions.

          Show
          Roger Butenuth added a comment - The problem seems to be more general for me: We use maven 2 to build a large project consisting of several modules. Dependencies between modules are handled by the maven dependency mechanism. During development, we want to use the SNAPSHOT feature because we don't want to have an inflation of version numbers. The problem: For me it looks like snapshots are never updated in the local repository. To track this down, I have done the following test: 1. Deploy "interface" to our central repository 2. Compile "client" (which depends on "interface") pom, jar and metadata are downloaded into local repository. 3. Increased version number and timestamp in the file 1.0-SNAPSHOT/maven-metadata.xml, recomputed checksums. 4. Run "mvn -U clean compile" on module "client". This results in the following log: [INFO] Scanning for projects... [INFO] -------------------------------------------------------------- -------------- [INFO] Building Client for the great calculator [INFO] task-segment: [clean, compile] [INFO] -------------------------------------------------------------- -------------- [INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-source-plugin: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from central [INFO] [clean:clean] [INFO] Deleting directory c:\example\client\target [INFO] Deleting directory c:\example\client\target\classes [INFO] Deleting directory c:\example\client\target\test-classes [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from central [INFO] [source-download:download-sources {execution: default} ] -----> [INFO] snapshot de.sdm.calculator:interface:1.0-SNAPSHOT: checking for updates from central <------ [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot de.sdm.calculator:calculator-all:1.0-SNAPSHOT: checking for updates from central [INFO] [compiler:compile] Compiling 1 source file to c:\example\client\target\classes [INFO] -------------------------------------------------------------- ---------- [INFO] BUILD SUCCESSFUL As you can see in the marked line, the check for updates is done. Looking into ~/.m2/repository I can see even the new maven-metadata-central.xml (new timestamp, new content), but the jar is NOT updated from the server. Is this intendented behaviour? I can solve the problem by setting <uniqueVersion>true</uniqueVersion> master pom of the project, but this clobberes the local repositories of all users and the central repository with lots of old versions.
          Hide
          Carlos Sanchez added a comment -

          can you provide a test case in code, please?

          Show
          Carlos Sanchez added a comment - can you provide a test case in code, please?
          Hide
          Roger Butenuth added a comment -

          I don't have a JUnit test case for this, but my "play project".
          To reproduce the bug:

          • mvn deploy the whole project (you need a server where you can deploy),
            do this in environment 1.
          • in envrionment 2 change something in "common" (directory name, maven
            name is "interface"
          • mvn deploy in environment 2
          • mvn -U install in environment 1
            Metadata in environment 1 will be updated, but jar will not be updated.
          Show
          Roger Butenuth added a comment - I don't have a JUnit test case for this, but my "play project". To reproduce the bug: mvn deploy the whole project (you need a server where you can deploy), do this in environment 1. in envrionment 2 change something in "common" (directory name, maven name is "interface" mvn deploy in environment 2 mvn -U install in environment 1 Metadata in environment 1 will be updated, but jar will not be updated.
          Hide
          Joerg Schaible added a comment -

          My attachment (mng2289.zip) contains a demo for the parent SNAPSHOT. It consists of two projects parent and issue. The parent POM defines a distribution snapshot repo at monospacedfile:///temp/repo-m2-snapshotmonospaced, so no harm is done

          Steps:

          1. Go to the parent directory and call noformat}}mvn deploy{{noformat
          2. Go to the issue directory and call noformat}}mvn eclipse:eclipse{{noformat, the project is now dependent on junit-3.7 as defined in the dependencyManagement of the parent
          3. Set your local repo in settings.xml to something else e.g. noformat<localRepository>/temp/repo-m2-local</localRepository>noformat
          4. Go to the parent directory and change the version of junit to 3.8
          5. Call again noformat}}mvn deploy{{noformat, but Maven will now use the temporary local repo for installation of the updated POM
          6. Go to the issue directory and call noformat}}mvn eclipse:eclipse{{noformat, the project is now dependent on junit-3.8 as defined in the dependencyManagement of the parent
          7. Restore your settings.xml
          8. Call noformat}}mvn eclipse:eclipse{{noformat again for the issue, the project is still dependent on junit-3.7 the available newer version of the snapshot parent is ignored

          The example is challenging, since the repo difinitions are in the parent POM itsefl, but evenm if you move them to your settings XML, the behaviour is not different.

          Show
          Joerg Schaible added a comment - My attachment (mng2289.zip) contains a demo for the parent SNAPSHOT. It consists of two projects parent and issue . The parent POM defines a distribution snapshot repo at monospaced file:///temp/repo-m2-snapshot monospaced , so no harm is done Steps: Go to the parent directory and call noformat}}mvn deploy{{noformat Go to the issue directory and call noformat}}mvn eclipse:eclipse{{noformat , the project is now dependent on junit-3.7 as defined in the dependencyManagement of the parent Set your local repo in settings.xml to something else e.g. noformat <localRepository>/temp/repo-m2-local</localRepository> noformat Go to the parent directory and change the version of junit to 3.8 Call again noformat}}mvn deploy{{noformat , but Maven will now use the temporary local repo for installation of the updated POM Go to the issue directory and call noformat}}mvn eclipse:eclipse{{noformat , the project is now dependent on junit-3.8 as defined in the dependencyManagement of the parent Restore your settings.xml Call noformat}}mvn eclipse:eclipse{{noformat again for the issue , the project is still dependent on junit-3.7 the available newer version of the snapshot parent is ignored The example is challenging, since the repo difinitions are in the parent POM itsefl, but evenm if you move them to your settings XML, the behaviour is not different.
          Hide
          yanke added a comment -

          Hi,
          we have the same problem when using the following configuration in our POM:

          Show
          yanke added a comment - Hi, we have the same problem when using the following configuration in our POM:
          Hide
          yanke added a comment -

          Hi,
          we have the same problem when using the following configuration in our POM:

          <snapshotRepository>
          <id>internalRepo</id>
          <name>our company internal repo</name>
          <url>ftp://maven.xxx.xxx/opt/repository/maven</url>
          <!-- uniqueVersion == false is needed to upload snapshots releases
          without changing fileName to timestamp+buildNumber.
          All deployment will override the -SNAPSHOT files on the repo. -->
          <uniqueVersion>false</uniqueVersion>
          </snapshotRepository>

          during deploy phase the -SNAPSHOT.jar on the server is overridden by the newer one and maven-metadata.xml is updated properly but when another client run maven (and has already the older version of the SNAPSHOT in its local repository) it doesn't download the newer pom and jar.

          maven (with debug enabled says):
          [DEBUG] Retrieving parent-POM: xxx:yyy::0.3.1-SNAPSHOT for project: xxx:zzz:jar:0.3.1-SNAPSHOT from the repository.
          [DEBUG] yyy: using locally installed snapshot

          if we run on the client maven with the -U option we get:
          [DEBUG] Retrieving parent-POM: xxx:yyy::0.3.1-SNAPSHOT for project: xxx:yyy:jar:0.3.1-SNAPSHOT from the repository.
          [INFO] snapshot xxx:yyy:0.3.1-SNAPSHOT: checking for updates from internalRepo
          [INFO] snapshot xxx:yyy:0.3.1-SNAPSHOT: checking for updates from central
          [DEBUG] repository metadata for: 'snapshot xxx:yyy:0.3.1-SNAPSHOT' could not be found on repository: central
          [DEBUG] yyy: using locally installed snapshot

          in both cases maven is not downloading the newest POM.
          Another strange thing is that after looking in our internalRepo it still looks in the central repo if the metadata are there. Maven should have found metadata information in our internalRepo (infact it DOES NOT give out the error (repository metadata for: 'snapshot xxx:yyy:0.3.1-SNAPSHOT' could not be found on repository: internalRepo). It seems maven find the metadata on our repo but not consider it.

          let me know if I can do some more test,
          best regards,
          Federico

          Show
          yanke added a comment - Hi, we have the same problem when using the following configuration in our POM: <snapshotRepository> <id>internalRepo</id> <name>our company internal repo</name> <url> ftp://maven.xxx.xxx/opt/repository/maven </url> <!-- uniqueVersion == false is needed to upload snapshots releases without changing fileName to timestamp+buildNumber. All deployment will override the -SNAPSHOT files on the repo. --> <uniqueVersion>false</uniqueVersion> </snapshotRepository> during deploy phase the -SNAPSHOT.jar on the server is overridden by the newer one and maven-metadata.xml is updated properly but when another client run maven (and has already the older version of the SNAPSHOT in its local repository) it doesn't download the newer pom and jar. maven (with debug enabled says): [DEBUG] Retrieving parent-POM: xxx:yyy::0.3.1-SNAPSHOT for project: xxx:zzz:jar:0.3.1-SNAPSHOT from the repository. [DEBUG] yyy: using locally installed snapshot if we run on the client maven with the -U option we get: [DEBUG] Retrieving parent-POM: xxx:yyy::0.3.1-SNAPSHOT for project: xxx:yyy:jar:0.3.1-SNAPSHOT from the repository. [INFO] snapshot xxx:yyy:0.3.1-SNAPSHOT: checking for updates from internalRepo [INFO] snapshot xxx:yyy:0.3.1-SNAPSHOT: checking for updates from central [DEBUG] repository metadata for: 'snapshot xxx:yyy:0.3.1-SNAPSHOT' could not be found on repository: central [DEBUG] yyy: using locally installed snapshot in both cases maven is not downloading the newest POM. Another strange thing is that after looking in our internalRepo it still looks in the central repo if the metadata are there. Maven should have found metadata information in our internalRepo (infact it DOES NOT give out the error (repository metadata for: 'snapshot xxx:yyy:0.3.1-SNAPSHOT' could not be found on repository: internalRepo). It seems maven find the metadata on our repo but not consider it. let me know if I can do some more test, best regards, Federico
          Hide
          Brett Porter added a comment -

          voters: please move your votes to MNG-1908!

          Show
          Brett Porter added a comment - voters: please move your votes to MNG-1908 !
          Hide
          Jason van Zyl added a comment -

          I will check with Kenney because I think this was fixed in trunk and I'll backport it if necessary.

          Show
          Jason van Zyl added a comment - I will check with Kenney because I think this was fixed in trunk and I'll backport it if necessary.
          Hide
          Jason van Zyl added a comment -

          Joerg, do you want to check this out:

          https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/MNG-2289

          I tried to mimic your test and simplify it and it appears to be working. The new parent POM is used and the updated dependency is used.

          Show
          Jason van Zyl added a comment - Joerg, do you want to check this out: https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/MNG-2289 I tried to mimic your test and simplify it and it appears to be working. The new parent POM is used and the updated dependency is used.
          Hide
          Patrick Schneider added a comment -

          When I run the IT that Jason just committed (https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/MNG-2289/), I see commons-logging-1.0.2 pulled in after re-deployment of the parent SNAPSHOT, showing that the child does pick up the newer version. So, at least with this test, I'm not able to reproduce the problem.

          Show
          Patrick Schneider added a comment - When I run the IT that Jason just committed ( https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources/MNG-2289/ ), I see commons-logging-1.0.2 pulled in after re-deployment of the parent SNAPSHOT, showing that the child does pick up the newer version. So, at least with this test, I'm not able to reproduce the problem.
          Hide
          Patrick Schneider added a comment -

          I was using 2.0.6.

          Show
          Patrick Schneider added a comment - I was using 2.0.6.
          Hide
          Jason van Zyl added a comment -

          Patrick and I cannot not reproduce this Jorg, so we're going to mark can't reproduce. Unless you want to take a look at the IT we whipped up and see if you can.

          Show
          Jason van Zyl added a comment - Patrick and I cannot not reproduce this Jorg, so we're going to mark can't reproduce. Unless you want to take a look at the IT we whipped up and see if you can.

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Joerg Schaible
            • Votes:
              19 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development