ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Re: Chain resolver chaos with local dependency overrides
Date Sun, 08 Mar 2009 19:32:14 GMT
Sunday, March 8, 2009, 8:06:21 PM, Gilles Scokart wrote:

> I do somthing similar.  When a developper has finish to play with a local
> dependency he must clean his local repository, clean his cache and
> re-execute a resolve.
> Not very nice, but in my context it seems to be OK (we rarely have to play
> with local dependencies).

I was nicer, and developers can issue 'ant publish-override' and 'ant
unpublish-override' in all projects (sub-projects), without
understanding much about what's going on. But it's implemented in a
dirty way. For one, it deletes from a cache with Ant <delete>... and I
guess I could avoid all those dirty things if Ivy works properly.

Anyway, if anyone else needs this, let it be in the mail archives...
Public Domain, I did it like this:

--- The ivysettings.xml: ---

        <!-- Include Ivy default resolver chain: -->
        <include url="${ivy.default.settings.dir}/ivysettings.xml" />
            <cache name="YOURCOMPANY-devel-cache" basedir="${user.home}/.ivy2/YOURCOMPANY-devel-cache"
            <cache name="YOURCOMPANY-devel-local-override-cache" basedir="${user.home}/.ivy2/YOURCOMPANY-devel-local-override-cache"
            <url name="zeroturnaround" m2compatible="true" cache="YOURCOMPANY-devel-cache">
                <artifact pattern="[module]/[revision]/[artifact]-[revision].[ext]"
            <chain name="YOURCOMPANY-devel" returnFirst="true">
                <filesystem name="YOURCOMPANY-devel-local-override" cache="YOURCOMPANY-devel-local-override-cache">
                    <ivy pattern="${user.home}/.ivy2/YOURCOMPANY-devel-local-override/[organisation]/[module]/ivy-[revision].xml"
                    <artifact pattern="${user.home}/.ivy2/YOURCOMPANY-devel-local-override/[organisation]/[module]/[artifact]-[revision].[ext]"
                <url name="YOURCOMPANY-devel-webserver" cache="YOURCOMPANY-devel-cache">
                    <ivy pattern="[organisation]/[module]/ivy-[revision].xml"
                    <artifact pattern="[organisation]/[module]/[artifact]-[revision].[ext]"
            <module organisation="com.YOURCOMPANY" resolver="YOURCOMPANY-devel" />
            <!-- stable releases are on Ibiblio *only*:  -->
            <module organisation="" revision="(.*branch-head.*)|(latest\.(integration|nightly|dev))"
resolver="YOURCOMPANY-devel" />

            <!-- These are not available in public resolvers, or are outdated: -->
            <module organisation="com.thaiopensource" name="jing" resolver="YOURCOMPANY-devel"
            <module organisation="javax.servlet.jsp" name="jsp-api" revision="1.2" resolver="YOURCOMPANY-devel"

            <!-- Not on Ibiblio: -->
            <module organisation="org.zeroturnaround" resolver="zeroturnaround" />

--- In Ant build.xml: ---

    <target name="publish-override" depends="jar"
            description="Ivy-publishes this project locally as an override"
                organisation="${moduleOrg}" module="${moduleName}"
                overwrite="true" forcedeliver="true"
            <artifacts pattern="build/artifacts/[artifact].[ext]" />
        <echo>*** Don't forget to `ant unpublish-override` later! ***</echo>

    <target name="unpublish-override" description="Undoes publish-override">
        <delete dir="${user.home}/.ivy2/YOURCOMPANY-devel-local-override/${moduleOrg}/${moduleName}"
        <delete dir="${user.home}/.ivy2/YOURCOMPANY-devel-local-override-cache/${moduleOrg}/${moduleName}"
    <target name="uninstall"
            description="Deletes external files created by YOURCOMPANY developement">
        <delete dir="${user.home}/.ivy2/YOURCOMPANY-devel-cache" />
        <delete dir="${user.home}/.ivy2/YOURCOMPANY-devel-local-override" />
        <delete dir="${user.home}/.ivy2/YOURCOMPANY-devel-local-override-cache" />

> Gilles Scokart
> 2009/3/8 Daniel Dekany <>
>> I have a chain-resolver that contains a filesystem-resolver and an
>> url-resolver. The filesystem-resolver is local to the developer's
>> workstation, while the url-resolver points to a webserver that is
>> common for all developers. Normally, Ivy just grabs all dependencies
>> from the webserver, but sometimes a developer wants to play locally
>> with a bleeding edge version of a *dependency* (which is not yet on
>> the webserver), so he publishes that with the filesystem-resolver, so
>> only on his workstation Ivy will use that from then. So far so good...
>> The problem is with using the version on the webserver again. I tried
>> two approaches:
>> (a)  Ivy should always check both repositories, and chose the version
>>    of the module that is the latest. With a chain and the default
>>    returnFirst="false" this works as far as the revision "number" of
>>    the older and newer stuff differs, but if only the publication
>>    date differs (like for two snapshots) Ivy always chooses the
>>    revision returned by the earlier resolver of the chain. It does
>>    so despite <dependency ... changing="true" />. I checked that Ivy
>>    downloads and parses the ivy.xml-s from both Ivy repositories, and
>>    that both XML contains correct <info publication="...">, yet Ivy
>>    always says that the one downloaded last was the older. That's
>>    despite that from the publication attributes it's obvious that it
>>    isn't so. Bug?
>> (b) After (a) failed, I decided that the filesystem-resolver will have
>>    priority over the url-resolver (i.e., returnFirst="true"), and I
>>    add an Ant task for un-publishing from the filesystem-resolver.
>>    (This last is needed for (a) too anyway.) First of all, there is
>>    no ivy:unpublish. Luckily I defined and control the
>>    filesystem-resolver, so I know what to ant-<delete>, so this part
>>    is worked around in this case. The problem is, after deleting from
>>    the filesystem-resolver, Ivy still find the module there through
>>    the cache. Shouldn't <dependency ... changing="true" />
>>    effectively bypass the cache? I checked it, and it kind of did.
>>    Ivy tries to open the files in the repository, and it realizes
>>    they are not there anymore. But then instead of continuing with
>>    the next resolver in the chain, it uses the cached copy of those
>>    files that it *knows* to be non-existent. I mean, a cache should
>>    reflect what it caches as precisely as it can, as far as it
>>    doesn't defeat the performance, and in this case the
>>    performance-defeating slow I/O was already done, so why the cache
>>    doesn't reflex the new situation? Bug?
>> And, the point... I guess I try to address a fairly common use-case
>> here. What solution you guys use for this? (I try to rely on
>> ivy:cachepath instead of ivy:retrieve.)
>> --
>> Best regards,
>>  Daniel Dekany

Best regards,
 Daniel Dekany

View raw message