First, thank you, to both you and Dave, for your suggestions. We decided to go with your suggestion. I've used the rpm installation of 3.2.0.
While most files our test builds required from the old Artifactory were pulled over and cached by the new one, I've run into some cases where they aren't. In the case of some files, I had to set the remote repos' checksum policy to "Ignore and generate", in order to get it to pull and cache some apparently unsavory bits on our old server. I only mention this so you'll know the next issue *isn't* this one. But now I have another batch of files that are failing to be pulled over. It seems to dislike some in-house-created maven plugin jars. It will pull the metadata file, then it will pull the pom file but then it doesn't pull the jar file - that is definitely there - and simply tells the build it can't find it. I've spent hours trying to figure out why, to no avail. If I download the offending jars from the old and manually deploy them to the new (which it happily takes), the build succeeds. If I build against the old server directly, the build succeeds. It's just that the new one won't pull it from the old one. I can't be manually intervening in 100's of builds until they have everything they need from the old, in the new. I set up a test so I could get logs for this. I truncated the logs on both artifactory servers and removed any evidence of the artifact from the new server and the build's .m2 directory, so it would be forced to try to pull it from the old server. The relevant portion of the build: http://pastebin.com/6xrWSCHH Old server's artifactory.log: http://pastebin.com/N9V0LuUL Old server's consoleout.log: http://pastebin.com/3j59Fvk4 New server's access.log: http://pastebin.com/uMcwUhK8 New server's artifactory.log: http://pastebin.com/zQ0e1YjE New server's request.log: http://pastebin.com/RS9sJPE7 I'm totally stumped. Any insight into this problem would be appreciated. The behavior is the same for each of the maven plugin jars, so if I solve this one, I likely solve them all. -ste > -----Original Message----- > From: itamarb [mailto:[email protected]] > ... > The upgrade process Dave refers to is the correct way to upgrade. > > Another option, if both instances are still running, would be to proxy each of > the old instance's repositories from the new instance ... ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
