Maven 2 & 3

snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0.1
  • Fix Version/s: 2.0.5
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

It seems from the log info that m2 is trying to locate the artifact metadata on the repository.
SInce this artifact has been generated from m1, there is no metadata.
So whatever repository settings are configured, m2 will never update snapsots.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-2289 Newer SNAPSHOT parents in the remote repository are ignored

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2601 mvn -U does NOT update/download the latest SNAPSHOT version

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-1919 If deploy with uniqueVersion=false (only generate file ended SNAPSHOT), this is not downloaded

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-3144 Snapshots not updated when using uniqueVersion false

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-3137 IT 0108 (snapshot updates) fail intermittently

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MNG-2780 snapshots are not updated based on metadata deployed with uniqueVersion = false

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2790 lastUpdated timestamp in local repository metadata not updated on install if it already exists

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

look into the unique version = false problem which is probably the same too

Show
Brett Porter added a comment - look into the unique version = false problem which is probably the same too
Hide
Permalink
Brett Porter added a comment -

downloading is fine, its the updating that's a problem

Show
Brett Porter added a comment - downloading is fine, its the updating that's a problem
Hide
Permalink
Brett Porter added a comment -

should be able to obtain this mix by merging r375485 and r375497 from the trunk to the maven-2.0.2 tag.

All trunk and branch builds will now contain it - eg:
http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060207.061502.tar.gz

Show
Brett Porter added a comment - should be able to obtain this mix by merging r375485 and r375497 from the trunk to the maven-2.0.2 tag. All trunk and branch builds will now contain it - eg: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060207.061502.tar.gz
Hide
Permalink
Brett Porter added a comment -

note that this is significantly slower when using local snapshots not in the reactor during a daily or forced update period. We should investigate a better solution.

Show
Brett Porter added a comment - note that this is significantly slower when using local snapshots not in the reactor during a daily or forced update period. We should investigate a better solution.
Hide
Permalink
Brett Porter added a comment -

fix only applied to trunk

Show
Brett Porter added a comment - fix only applied to trunk
Hide
Permalink
Brett Porter added a comment -

need to investigate the performance regression caused by these revisions

Show
Brett Porter added a comment - need to investigate the performance regression caused by these revisions
Hide
Permalink
Claus M. Vagner added a comment -

Can I please get an update on this issue...

I have ran into the problem with maven not updating the snapshot locally if present. The snapshot release is not generated with maven but uploaded manually.

Will this be fixed no earlier then 2.1?

Show
Claus M. Vagner added a comment - Can I please get an update on this issue... I have ran into the problem with maven not updating the snapshot locally if present. The snapshot release is not generated with maven but uploaded manually. Will this be fixed no earlier then 2.1?
Hide
Permalink
Adam Lewis added a comment -

I have a similar problem. The artifacts are deployed using m2, the metadata on the repo is generated. When I do a build, maven logs that it has found a snapshot version and is checking for updates. It downloads and updates my local metadata for that repo, but DOES NOT download the updated JAR.

THIS IS A BLOCKING ISSUE. If a release is not planned soon, the fix needs to be back ported.

Having snapshots that don't update reduces the usefullness of SNAPSHOT to ZERO. Actually its worse than that, because we expect that SNAPSHOTS be updated from our internal repo and maven behaves as if it is updating them and then it does NOTHING. A fix in 2.1 does nothing for us if 2.1 doesn't get releases soon.

Show
Adam Lewis added a comment - I have a similar problem. The artifacts are deployed using m2, the metadata on the repo is generated. When I do a build, maven logs that it has found a snapshot version and is checking for updates. It downloads and updates my local metadata for that repo, but DOES NOT download the updated JAR. THIS IS A BLOCKING ISSUE. If a release is not planned soon, the fix needs to be back ported. Having snapshots that don't update reduces the usefullness of SNAPSHOT to ZERO. Actually its worse than that, because we expect that SNAPSHOTS be updated from our internal repo and maven behaves as if it is updating them and then it does NOTHING. A fix in 2.1 does nothing for us if 2.1 doesn't get releases soon.
Hide
Permalink
Tom Spengler added a comment -

2.1 is realy to late for us,

we (100 persons) cannot every day update there local repository with more than 300 artifacts per hand

we need a solution nearly today!!

Show
Tom Spengler added a comment - 2.1 is realy to late for us, we (100 persons) cannot every day update there local repository with more than 300 artifacts per hand we need a solution nearly today!!
Hide
Permalink
Brett Porter added a comment -

the current fix has resulted in a regression in the release update functionality. Another IT is in order.

Show
Brett Porter added a comment - the current fix has resulted in a regression in the release update functionality. Another IT is in order.
Hide
Permalink
Brett Porter added a comment -

fixed, again

Show
Brett Porter added a comment - fixed, again
Hide
Permalink
Jay Kirby added a comment -

This is still an issue in 2.0.5. I can never get an artifact with a non-unique version number containing SNAPSHOT to update in the local repository. I get a message like:

[DEBUG] repository metadata for: 'snapshot mygroup:myartifact:main-SNAPSHOT' could not be found on repository: devst

even though it appears as though the correct metadata is present on the remote server. A new maven-metadata-devst.xml is created in the local repository, but none of the artifacts are pulled.

How do I reopen this?

Show
Jay Kirby added a comment - This is still an issue in 2.0.5. I can never get an artifact with a non-unique version number containing SNAPSHOT to update in the local repository. I get a message like: [DEBUG] repository metadata for: 'snapshot mygroup:myartifact:main-SNAPSHOT' could not be found on repository: devst even though it appears as though the correct metadata is present on the remote server. A new maven-metadata-devst.xml is created in the local repository, but none of the artifacts are pulled. How do I reopen this?
Hide
Permalink
Jay Kirby added a comment -

Finally got this to work by packaging and deploying using m2 after the m1 build completed. It only seems to work if the artifacts in the remote repository have unique names (i.e. with the timestamp in it). You then end up with two copies of the artifact in the local repo, one with the unique name (i.e. myartifactid-1.0-20070222.002933-1.jar) and one with the abbreviated artifactid-versionid name (i.e. myartifact-1.0-SNAPSHOT.jar). Kind of a waste of space, but at least it works...

Show
Jay Kirby added a comment - Finally got this to work by packaging and deploying using m2 after the m1 build completed. It only seems to work if the artifacts in the remote repository have unique names (i.e. with the timestamp in it). You then end up with two copies of the artifact in the local repo, one with the unique name (i.e. myartifactid-1.0-20070222.002933-1.jar) and one with the abbreviated artifactid-versionid name (i.e. myartifact-1.0-SNAPSHOT.jar). Kind of a waste of space, but at least it works...
Hide
Permalink
Jason van Zyl added a comment -

This does not appear to be fixed and is related to MNG-2289.

Show
Jason van Zyl added a comment - This does not appear to be fixed and is related to MNG-2289 .
Hide
Permalink
Brett Porter added a comment -

Jason, I have test cases in the integration tests showing this works, and they run in every environment I have ever run them in.

Do you have:

  • an additional test case that shows it doesn't work, or
  • an environment where the test cases fail?

If not, I'd prefer to leave this closed for 2.0.5 and open new issues for any new issues found with the functionality.

Show
Brett Porter added a comment - Jason, I have test cases in the integration tests showing this works, and they run in every environment I have ever run them in. Do you have: an additional test case that shows it doesn't work, or an environment where the test cases fail? If not, I'd prefer to leave this closed for 2.0.5 and open new issues for any new issues found with the functionality.
Hide
Permalink
Brett Porter added a comment -

this was fixed in several scenarios in 2.0.5. Any related problems are being filed as new issues.

Show
Brett Porter added a comment - this was fixed in several scenarios in 2.0.5. Any related problems are being filed as new issues.

People

  • Assignee:
    Brett Porter
    Reporter:
    Guillaume Nodet
Vote (36)
Watch (29)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
30m
Original Estimate - 30 minutes Original Estimate - 30 minutes
Remaining:
0m
Remaining Estimate - 0 minutes
Logged:
2h 30m
Time Spent - 2 hours, 30 minutes