Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 nicolas.lalevee@hibnet.org does not designate 216.86.168.182 as permitted
 sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Using ivy:retrieve sync="true" deletes my non-ivy managed jars
From: =?iso-8859-1?Q?Nicolas_Lalev=E9e?= <nicolas.lalevee@hibnet.org>
In-Reply-To: <513ADA7B-4080-4AB6-A2E1-0A738386FD59@willowtreeapps.com>
Date: Sat, 1 Oct 2011 00:04:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3FE5A34-4BAE-4A32-A85B-8B6C948773C2@hibnet.org>
References: <99A4877A-E249-40A2-AD2A-6BC4A5756330@willowtreeapps.com>
 <4E85C68D.3050502@masergy.com>
 <513ADA7B-4080-4AB6-A2E1-0A738386FD59@willowtreeapps.com>
To: ivy-user@ant.apache.org


Le 30 sept. 2011 =E0 20:38, Michael Lake a =E9crit :

>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> =46rom 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.
>=20
> Here's my current workaround which is a bit of a hack..
>=20
>       <delete>
>            <fileset dir=3D"${ivy.lib.dir}" includes=3D"oak-library*"/>
>        </delete>
>        <ivy:retrieve/>
>=20
> 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.
>=20
> 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=3D"adhocjars">
	<artifact pattern=3D"${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.=20
> But=85I 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.
>=20
> Michael Lake
> Senior Software Developer
> WillowTree Apps
> O 434-326-4341 | M 434.202.9223
>=20
>=20
> On Sep 30, 2011, at 9:39 AM, Kirby Files wrote:
>=20
>> Michael Lake wrote on 09/30/2011 09:11 AM:
>>=20
>>> let's say I modify my ivy.xml to use a different version of oak, say =
version 1.0.4
>> [...]
>>>=20
>>> $ ant init-ivy-sync # here's it's doing<ivy:retrieve sync=3D"true" =
/>
>>>=20
>>> $ 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
>>=20
>> Yes, that's the way sync=3Dtrue works. You're telling Ivy that you'd =
like it to manage the jars in the destination directory.
>>=20
>>> 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)
>>>=20
>>> how can I accomplish this?
>>=20
>> 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:
>>=20
>> * 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
>>=20
>> 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?
>>=20
>> 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.
>>=20
>> Thanks,
>> ---
>> Kirby Files
>> Software Architect
>> Masergy Communications
>> kfiles@masergy.com
>=20