Your steps are correct. If you are doing this for work, then never ever depend on a public repository. You have no control over it and things do change (even when they shouldn't).
Your best bet is too either: 1) maintain an inhouse repo (and have it tape backuped) 2) or setup an archive proxy (see the maven project for those sort of things) I tend to do #1 as it allows me the most control. -----Original Message----- From: Mathew Joseph [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 2:58 PM To: [email protected] Subject: Migration to IVY Hello there, The 3rd party dependencies that our project depends on are stored in subversion and are retrieved as part of an svn checkout along with the source code. Dependency management is non existent. We are about to migrate to an IVY based system and I wanted to know what is the experience of people who might have attempted something similar. Steps I will need to take. 1. Identify exact version number of the dependencies and transitive dependencies that we are using 2. Move them into a maven or custom repository format hosted either in subversion or plain file system served by http. I believe the idea is to ensure that I only resolve the first level dependency in my scripts and all transitive dependencies are pulled in by IVY. However, this means my custom repository needs to have either via pom.xml or ivy.xml defined for all first level dependencies. I was wondering that it will be very time consuming for me to recreate the artifact repository from scratch. Do you guys think it makes sense to create a ivy.xml with version numbers and have ivy resolve them from a public repository. Once I do a retrieve, I then use the local cache as the first version of my custom repository and then start adding in all the dependencies that I did not find in public repos. This will ensure the repository has ivy.xml for all dependencies. Then close out ivysettings.xml to use only the internal http resolver as opposed to looking out in public repos. I am more inclined to use a maven repository style as opposed to a custom one since I can then use maven repository managers to handle proxying and mirroring other public repos. My thoughts are a bit random on this, but I hope you get the general picture.. regards, Mathew Joseph Build & Release Engineer Bravura Solutions
