The JAR files are still in the cache of IVY. The classpath is simply automatically generated by IVY and points to the JARs in the ivy cache. So disk space is still used. But you spare lots of space if you have multiple checkouts :-)
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Michael McCandless [mailto:[email protected]] > Sent: Tuesday, March 27, 2012 9:34 PM > To: [email protected] > Subject: Re: switch jars to ivy mechanism? > > +1 > > I could save a huge amount of disk space with this :) > > Mike McCandless > > http://blog.mikemccandless.com > > On Tue, Mar 27, 2012 at 3:28 PM, Robert Muir <[email protected]> wrote: > > Hello everyone, > > > > There is currently a thread about jars going on another list, this > > isn't about that. > > > > But just reading over the thread and thinking about things, our svn > > checkout is quite large because of checked in jars. I don't think this > > is good for developers in Europe or Japan or elsewhere, because it > > makes the checkout huge. > > > > On the other hand I look at the example ivy file from the tutorial > > (http://ant.apache.org/ivy/history/latest-milestone/samples/build.xml) > > and it looks pretty nice. I know there is an eclipse plugin that works > > with this as well. > > > > I was thinking about experimenting with our build to remove these jars > > (at least: as many as possible) and see how ivy worked, purely as an > > optimization. It seems like maybe it really wouldnt be such a huge > > change... maybe something that could be done in a day or something > > like that. > > > > Does anyone have any opinions on this? > > > > -- > > lucidimagination.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
