ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirby Files <kfi...@masergy.com>
Subject Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
Date Fri, 30 Sep 2011 13:39:25 GMT
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
kfiles@masergy.com

Mime
View raw message