Additionally, removing all JARs on "ant clean" is hoorible for IDE users, because those would loose JARs from their classpath.
As Robert said, for Eclipse it might be better to depend on IvyDE plugin, which works great and does the same like the building class-path from Ivy cache (ivy:cachepath/ivy:cachefileset). You right click on the ivy.xml file and Eclipse adds all referenced JARs to your internal build path. It then appears like a "library" in Eclipse sense. So +1 on a new issue to cleanup the build in trunk to no longer copy any JARs around (nuke ivy-resolve task) and instead build all classpath with <ivy:cachepath property="..."/> and build all ZIPs/WARs/... with <ivy:cachefileset/> inside the zip tasks. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Robert Muir [mailto:[email protected]] > Sent: Tuesday, April 03, 2012 12:31 AM > To: [email protected] > Subject: Re: Upgrades to jars after moving to ivy. > > On Mon, Apr 2, 2012 at 6:29 PM, Chris Hostetter <[email protected]> > wrote: > > > > : I've just modified ivy.xml to use jackson 1.7.4 and this triggered > > an > > : interesting situation in which I ended up having two versions of > > : jackson in my checkout. This begs the question of what should we be > > : doing to remove stale JARs on an update of ivy descriptors. Should > > : "ant clean" remove all the JARs? > > > > rmuir added "clean-jars" ... but i was kind of wondering hte same thing. > > > > prior to ivy, an "svn up && ant clean" would get you into a good state > > because the svn up would remove the old jars ... seems like we should > > just make clean call clean-jars (if they *haven't* changed they'll > > still be in your ivy cache) > > > > This is way too much effort for what you will get. effort better spent > removing > lib/ and 'copies of jars' totally and instead having ivy just put this in the > classpath. > > The reason it is the way it is: is to not break packaging etc tasks. > IFF someone wants to open an issue and clean all this up and fix and test all > of > the packaging logic, thats fine for trunk. but its not ok for the branch. > > -- > 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]
