ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Haynes <>
Subject Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
Date Fri, 30 Sep 2011 16:51:07 GMT
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 <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message