I have a use case that I personally use. I have an ant script that does: - generates a developer setup environment. (retrieve dependencies, generate IDE project files, generate some other files, etc.) - run the test in this environment.
When I generate the developer environment, I use make a complete resolution. But when the developer later run its test, I use the result of the previous resolution. I do this because it is faster, and also because I'm sure it is in line with the developer environment. But I'm sure that there are other use case for that. By the way, you can try the 2.0-alpha2 release ;-) (even there is is bug [1] with the feature I just explained here, but that you anyway doesn't use). [1] https://issues.apache.org/jira/browse/IVY-583 Gilles 2007/7/30, Gregoire Henry <[EMAIL PROTECTED]>: > Gilles, I agree with your explanation, but are you effectively saying > that you can use a such produced files in a build for another project ? > or for another build in the same project .. I can't imagine a use case > for that .. can you explain me this practice ? > > > Maarten : unfortunatly we are still using (in production) the 1.4.1 > release ... planning to switch to 2.0.0 as soon as the ivy team can > release it ;-) > > > > Gilles Scokart a écrit : > > By the way, the reason to keep those files in the cache is to allow to > > reuse them an other build execution. When you launch a resolve > > (explicitely or implicitely), you can either provide an ivy file (the > > usual case that make a real resolve), or you can specify a module name > > and its organisation. In this second case, the xml file you are > > mentioning will be used used instead of the ivy file, the result of > > the previous resolve execution will be used. > > > > We should maybe make that optional. > > > > Gilles > > > > 2007/7/27, Maarten Coene <[EMAIL PROTECTED]>: > > > >> You could use the resolveId attribute on the ant tasks to solve your > >> problem. This attribute has been introduced in ivy-2.0.0-alpha1. > >> > >> When you use the resolveId, the generated xml files are > >> [resolveId]-[conf].xml. > >> If you choose a unique resolveId for each build (you could use a timestamp > >> as part of the resolveId for instance), you are sure that you don't have a > >> conflict regarding these XML files. > >> > >> regards, > >> Maarten > >> > >> ----- Original Message ---- > >> From: Gregoire Henry <[EMAIL PROTECTED]> > >> To: [email protected] > >> Sent: Friday, July 27, 2007 5:21:14 PM > >> Subject: problem with work files created in cache by ivy:resolve (ivy 1.4) > >> > >> hello > >> > >> I have a problem with the files created by ivy in the cache during the > >> resolve phase .. > >> Ivy create some files nammed [org]-[module]-[conf].xml in the cache , > >> should'nt those files be created in a temporary location outside of the > >> cache, and preferably in project specific directory ? > >> > >> My use case is the following > >> > >> We have a Continuous Build Server who can build at the same time several > >> different build from the same project .... > >> In my build i create a clean.resolve task for deleting the > >> [org]-[module]-[conf].xml files at the beginnig of each build ... as we > >> can have multiple build at the same time for the same project > >> I sometime have some build failled because of the deletion of this files > >> by another starting build ... > >> > >> I still have created different cache location for my different project , > >> but this use case should drive me to create a different cache for each > >> build !!! > >> > >> Have you a solution for that ? > >> would it be possible to have an ivy.temp.dir properties ? > >> Is there a different implementation in 2.0.0 ? > >> > >> > >> regards > >> > >> Greg > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ____________________________________________________________________________________ > >> Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated > >> for today's economy) at Yahoo! Games. > >> http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow > >> > >> > > > > > > > > -- Gilles SCOKART
