You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Michael Lake <mi...@willowtreeapps.com> on 2011/09/30 15:11:35 UTC
Using ivy:retrieve sync="true" deletes my non-ivy managed jars
$ ls -1 libs/ # list out the libs directory which the only jar that is managed by ivy is the oak-library*.jar
AdServer.jar
Facebook.jar
FlurryAgent.jar
asmack-jse-buddycloud-2010.12.11.jar
httpmime-4.1.1.jar
oak-library-1.0.5-SNAPSHOT-javadoc.jar
oak-library-1.0.5-SNAPSHOT-sources.jar
oak-library-1.0.5-SNAPSHOT.jar
ocpsoft-pretty-time-1.0.7.jar
signpost-commonshttp4-1.2.1.1.jar
signpost-core-1.2.1.1.jar
twitter4j-core-android-2.2.3.jar
let's say I modify my ivy.xml to use a different version of oak, say version 1.0.4
$ ant init-ivy # here's it's doing <ivy:retrieve sync="false" />
$ ls -1 libs/ # now I've got duplicates
AdServer.jar
Facebook.jar
FlurryAgent.jar
asmack-jse-buddycloud-2010.12.11.jar
httpmime-4.1.1.jar
oak-library-1.0.4-javadoc.jar
oak-library-1.0.4-sources.jar
oak-library-1.0.4.jar
oak-library-1.0.5-SNAPSHOT-javadoc.jar
oak-library-1.0.5-SNAPSHOT-sources.jar
oak-library-1.0.5-SNAPSHOT.jar
ocpsoft-pretty-time-1.0.7.jar
signpost-commonshttp4-1.2.1.1.jar
signpost-core-1.2.1.1.jar
twitter4j-core-android-2.2.3.jar
$ 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
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?
Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
Posted by David Haynes <da...@gmail.com>.
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 <kf...@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
> kfiles@masergy.com
>
Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 30 sept. 2011 à 20:38, Michael Lake a écrit :
>
> Obviously, getting things working "out-of-the-box" for the most common scenarios will help lower the barrier to adoption for Ivy. Perhaps by explaining my use-case, it would help paint a better picture of the path of a new user.
>
> I'm dabbling with Ivy as a light-weight method to grab snapshots of a shared library which is built with maven2 on our continuous integration server and published to our internal repo.
>
> The library is a jar that we want to use in our android projects and we're working towards making it open source. Since Android already creates an Ant build configuration, it seems to make sense to use Ivy as a method of pulling releases/snapshots from our repo for our shared library with minimal intrusion into existing projects. This is attractive compared with making our Android projects into Maven projects which just requires too much overhead - not only for us as an internal company, but also for end users who may not be so savvy with dependency management.
>
> From a new-user perspective, it seemed to me that Ivy should do a quick scan of the output directory and use the output pattern [artifact]-[revision].[ext] as a way of determining if there already existing artifacts copied to this dir and if there are, see if we need to delete them because we'll be bringing in a different version of the same artifact.
>
> Here's my current workaround which is a bit of a hack..
>
> <delete>
> <fileset dir="${ivy.lib.dir}" includes="oak-library*"/>
> </delete>
> <ivy:retrieve/>
>
> This will go in an imported ant build file which is to be copied into any projects which use the library - works, but not ideal.
>
> I'd rather see Ivy do what I want as a new user right out of the box (or at least with a simple flag). Sure, there's always the possibility that the Ivy output pattern gets changed and some jars might get left laying around, but I think that's a small price to pay to give new users a little more momentum with Ivy.
Having jar laying around in a classpath is not a good idea. Even without that we can have some "jar hell". I wouldn't recommend a such practice.
And about implementing what you're suggesting, I could not answer better than as Kirby already did.
If I may suggest another solution: put your adhoc jars in an Ivy repository so Ivy will manage them as regular dependencies.
By this solution, I don't mean having a file server somewhere, you can do it with a simple folder next to your project with a minimalist pattern. In your ivysettings you could put something like:
<filesystem name="adhocjars">
<artifact pattern="${adhocjars.dir}/[artifact]-[revision].[ext]" />
</filesystem>
But I don't know your use case well, maybe you use Ivy mainly as an automatic downloader rather than a dependency manager, the above solution maybe overkill.
Nicolas
> I'm sure I'm only scratching the surface of Ivy capability - I'm by no means an expert and not looking to be one.
> But…I imagine once we've got a few projects with these ivy.xml files laying around, rather than hunting down the latest version of commons-lang from apache's website, we'll be using ivy.xml to bring in new libraries. And by then we'll be hooked.
>
> Michael Lake
> Senior Software Developer
> WillowTree Apps
> O 434-326-4341 | M 434.202.9223
>
>
> On 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
>> kfiles@masergy.com
>
Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
Posted by Michael Lake <mi...@willowtreeapps.com>.
Obviously, getting things working "out-of-the-box" for the most common scenarios will help lower the barrier to adoption for Ivy. Perhaps by explaining my use-case, it would help paint a better picture of the path of a new user.
I'm dabbling with Ivy as a light-weight method to grab snapshots of a shared library which is built with maven2 on our continuous integration server and published to our internal repo.
The library is a jar that we want to use in our android projects and we're working towards making it open source. Since Android already creates an Ant build configuration, it seems to make sense to use Ivy as a method of pulling releases/snapshots from our repo for our shared library with minimal intrusion into existing projects. This is attractive compared with making our Android projects into Maven projects which just requires too much overhead - not only for us as an internal company, but also for end users who may not be so savvy with dependency management.
From a new-user perspective, it seemed to me that Ivy should do a quick scan of the output directory and use the output pattern [artifact]-[revision].[ext] as a way of determining if there already existing artifacts copied to this dir and if there are, see if we need to delete them because we'll be bringing in a different version of the same artifact.
Here's my current workaround which is a bit of a hack..
<delete>
<fileset dir="${ivy.lib.dir}" includes="oak-library*"/>
</delete>
<ivy:retrieve/>
This will go in an imported ant build file which is to be copied into any projects which use the library - works, but not ideal.
I'd rather see Ivy do what I want as a new user right out of the box (or at least with a simple flag). Sure, there's always the possibility that the Ivy output pattern gets changed and some jars might get left laying around, but I think that's a small price to pay to give new users a little more momentum with Ivy.
I'm sure I'm only scratching the surface of Ivy capability - I'm by no means an expert and not looking to be one.
But…I imagine once we've got a few projects with these ivy.xml files laying around, rather than hunting down the latest version of commons-lang from apache's website, we'll be using ivy.xml to bring in new libraries. And by then we'll be hooked.
Michael Lake
Senior Software Developer
WillowTree Apps
O 434-326-4341 | M 434.202.9223
On 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
> kfiles@masergy.com
Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
Posted by Kirby Files <kf...@masergy.com>.
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