You could create "fake" ivy.xml files that declare they are your mis-named org/name artifacts, and simply have them declare a dependency on the correct org/name artifacts. So if your internal repo has org="not-quite-junit" name="not-quite-junit" version="0.0.1", you can make a "not-quite-junit/not-quite-junit-0.0.1" package that has no artifacts and declares a transitive dependency on "junit/junit-4.1". Then when your 1200 projects resolve their Ivy dependencies on "not-quite-junit", they end up with junit in their classpath and you don't have to change any of the 1200 projects.
-Kent -----Original Message----- From: James Carr [mailto:[email protected]] Sent: Wednesday, April 13, 2011 8:43 AM To: [email protected] Subject: Read all organizations, artifafact names, and revs from a repo? Hi All, I'm getting around to help migrate a badly maintained flat file third party jar repo to resolve third party jars from nexus. An unfortunate problem is the existing flat file repo had jars manually downloaded with ivy.xml files created by hand so the orgs and names don't match reality. This is exacerbated by well over 1,200 projects with dependencies on these artifacts. I think it goes without saying that converting projects to use the right organizations and names would be a lot of work. ;) So I got to thinking... is there some way I could use ivy and the existing ivy pattern resolver to compile a list of orgs and names that could then be matched up with reality? From there it'd probably be a simple matter of crawling the internal repository and programmatically updating all the ivy.xmls. Thanks, James
