Since you are using Ant, you could create a copy task that will copy your libraries from a 'safe' location to your lib area after the ivy:retrieves have completed.
Alternately, if you are running your own maven repository, you could publish you libraries to it and use ivy:retrieve to populate them for you. On Fri, Sep 30, 2011 at 9:39 AM, Kirby Files <kfi...@masergy.com> wrote: > Michael Lake wrote on 09/30/2011 09:11 AM: > > let's say I modify my ivy.xml to use a different version of oak, say >> version 1.0.4 >> > [...] > >> >> $ ant init-ivy-sync # here's it's doing<ivy:retrieve sync="true" /> >> >> $ ls -1 libs/ # as you can see, everything else gets deleted >> oak-library-1.0.4-javadoc.jar >> oak-library-1.0.4-sources.jar >> oak-library-1.0.4.jar >> > > Yes, that's the way sync=true works. You're telling Ivy that you'd like it > to manage the jars in the destination directory. > > ideally, I'd like to just have the oak-library*.jars change and everything >> else be left alone (and no, I don't want to stick my other libs in the >> repository) >> >> how can I accomplish this? >> > > Do you have a proposal as to how you'd like Ivy to know which jars to > remove, if you only wanted jars previously retrieved by Ivy deleted? > Consider the possible modifications you may have made to ivy.xml or > ivysettings.xml: > > * change a module revision > * change the source repo for the module > * change the artifacts retrieved for a module > * remove one or more modules from ivy.xml > > Since the old copy of the ivy.xml isn't available for a diff, where would > you keep the data on what jars "belong" to ivy? Keep a file which stores all > artifacts downloaded, with filenames, hashes, etc.? Would that file survive > a cacheclean? Or would a cacheclean cause ivy to forget what had been > previously downloaded? What if a jar already exists with the same name as an > artifact Ivy would retrieve, but a different hash? Or a jar with the same > module name but no/different revision than ivy would retrieve? > > The current behavior is straightforward to explain and implement, which is > a virtue. That said, I imagine the Ivy devs would be willing to consider a > patch to a different or additional mode of operation, if you thought through > the ramifications, not limited to the ones listed above. > > Thanks, > --- > Kirby Files > Software Architect > Masergy Communications > kfi...@masergy.com >
