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: ---
<ivysettings>
<!-- Include Ivy default resolver chain: -->
<include url="${ivy.default.settings.dir}/ivysettings.xml" />
<caches>
<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" />
</caches>
<resolvers>
<url name="zeroturnaround" m2compatible="true"
cache="YOURCOMPANY-devel-cache">
<artifact
pattern="http://repos.zeroturnaround.com/maven2/org/zeroturnaround/[module]/[revision]/[artifact]-[revision].[ext]";
/>
</url>
<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]"
/>
</filesystem>
<url name="YOURCOMPANY-devel-webserver"
cache="YOURCOMPANY-devel-cache">
<ivy
pattern="https://YOURCOMPANY.com/repos/ivy/[organisation]/[module]/ivy-[revision].xml";
/>
<artifact
pattern="http://YOURCOMPANY.org/repos/ivy/[organisation]/[module]/[artifact]-[revision].[ext]";
/>
</url>
</chain>
</resolvers>
<modules>
<module organisation="com.YOURCOMPANY" resolver="YOURCOMPANY-devel"
/>
<!-- com.open.YOURCOMPANY stable releases are on Ibiblio *only*:
-->
<module organisation="com.open.YOURCOMPANY"
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"
/>
</modules>
</ivysettings>
--- In Ant build.xml: ---
<target name="publish-override" depends="jar"
description="Ivy-publishes this project locally as an override"
>
<ivy:publish
organisation="${moduleOrg}" module="${moduleName}"
pubrevision="${moduleBranch}-branch-head"
overwrite="true" forcedeliver="true"
resolver="YOURCOMPANY-devel-local-override"
>
<artifacts pattern="build/artifacts/[artifact].[ext]" />
</ivy:publish>
<echo>*** Don't forget to `ant unpublish-override` later! ***</echo>
</target>
<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>
<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"
/>
</target>
> Gilles Scokart
>
>
> 2009/3/8 Daniel Dekany <[email protected]>
>
>> 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
