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
>> [email protected]
>
