We changed the Maven Snapshot Version Behavior in our snapshot repository this morning from non-unique to unique and have seen errors with the first build of any project that deploys a snapshot artifact.
The error from the Maven client is: • [INFO] Error installing artifact's metadata: Error while deploying metadata: Resource to deploy not found: File: http://xxxxx.xxxxx.com/artifactory/<repositoryName>/<full>/<group>/<id>/<path>/<artifactId>/1.0.0-SNAPSHOT/<artifactiId>-1.0.0-SNAPSHOT.pom.md5 does not exist The artifact gets uploaded and deployed followed by the pom file but when the pom's md5 file gets uploaded, the above error is sent to the Maven client. There is no error in any of the Artifactory logs. These are the relevant entries in the artifactory.log (scrubbed): 2012-06-13 09:04:50,085 [http-4580-174] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/artifactid-1.0.0-SNAPSHOT.jar' Content-Length: 24891 2012-06-13 09:04:50,210 [http-4580-113] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/artifactid-1.0.0-SNAPSHOT.jar.md5' Content-Length: 32 2012-06-13 09:04:50,319 [art-exec-15670] [INFO ] (o.a.s.a.ArchiveIndexer:99) - The content of the archive: 'artifactid-1.0.0-20120613.140450-2.jar' was indexed successfully. 2012-06-13 09:04:50,319 [http-4580-109] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/artifactid-1.0.0-SNAPSHOT.jar.sha1' Content-Length: 40 2012-06-13 09:04:50,366 [http-4580-109] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/maven-metadata.xml' Content-Length: 365 2012-06-13 09:04:50,413 [http-4580-83] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/maven-metadata.xml.md5' Content-Length: 32 2012-06-13 09:04:50,413 [http-4580-63] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/maven-metadata.xml.sha1' Content-Length: 40 2012-06-13 09:04:50,444 [http-4580-63] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/maven-metadata.xml' Content-Length: 324 2012-06-13 09:04:50,444 [http-4580-54] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/maven-metadata.xml.md5' Content-Length: 32 2012-06-13 09:04:50,460 [http-4580-5] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/maven-metadata.xml.sha1' Content-Length: 40 2012-06-13 09:04:50,476 [http-4580-5] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/artifactid-1.0.0-SNAPSHOT.pom' Content-Length: 3416 2012-06-13 09:04:50,554 [http-4580-136] [INFO ] (o.a.e.UploadServiceImpl:178) - Deploy to 'RepositoryName:full/group/id/path/artifactid/1.0.0-SNAPSHOT/artifactid-1.0.0-SNAPSHOT.pom.md5' Content-Length: 32 This error only happens on the first deploy of an artifact when the artifact and pom already exist from a previous deploy from when the version behavior was to store non-unique snapshots. The second deploy always works so far. This error does not happen for projects deploying a pom like a parent pom project. The error also does not occur if any of the folders for the artifact do not already exist. I suspect this is one of the weirdness conditions talked about earlier if we did not delete all the snapshots after changing the setting to unique snapshots. I'm not sure there is anything that can be done other than deleting the non-unique snapshots. I wanted to post this in case others see similar behavior. Regards, --Ken From: Pacileo, Ken Sent: Monday, June 11, 2012 1:53 PM To: [email protected] Subject: Re: [Artifactory-users] Convert Snapshot repository to unique Thank you Yossi and Noam, Yossi – I am a little confused about your comment of “if you use automatic latest snapshot resolution”. Isn’t automatic latest snapshot resolution the default behavior for Maven when the repository behavior is defined as unique snapshots? It sounds like we can do the conversion and delete the non-unique snapshots over time as teams run builds that deploy unique versions. Unfortunately all teams deploy to the same repository so there’s no way to test it with one team. I have backups so I can revert to a backup if anything weird starts happening. Thanks for the information. Regards, --Ken From: Yossi Shaul [mailto:[email protected]] Sent: Sunday, June 10, 2012 11:28 AM To: [email protected] Subject: Re: [Artifactory-users] Convert Snapshot repository to unique Hi Ken, You may keep the old non-unique snapshots if you like. Mixing unique and non-unique snapshots for the same artifact might lead to weird behavior if you use automatic latest snapshot resolution or replication with different snapshot behavior. But other than that it is OK. I still recommend deleting the non-unique artifacts of active modules (modules you deploy new unique snapshots). HTH, Yossi On Sat, Jun 9, 2012 at 12:14 AM, Pacileo, Ken <[email protected]> wrote: Hi, We've been putting off upgrading our projects to Maven 3 because to do so requires changing our snapshot repository's snapshot version behavior from non-unique to unique. The documentation (http://wiki.jfrog.org/confluence/display/RTF/Local+Repositories) states to change the snapshot policy to unique and to remove any previously deployed snapshots from the repository. Our snapshot repository contains 840 artifacts (using Artifactory version 2.4.2) across 27+ project teams. My question is whether it is absolutely necessary to remove any previously deployed snapshots and what are the implications if we do not remove the snapshots? I didn't have any luck Googl'ing to see if someone else had this question nor did a search on Nabble get any relevant hits. Any help is appreciated in understanding our options. I'd like to make as minimal impact as possible to our users since the project teams are in various countries and their release schedules could be affected by any work disruption. Thanks and regards, --Ken Ken Pacileo | Continuous Integration Services | UnitedHealth Group IT This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
