[jira] [Comment Edited] (IVY-654) Share cache with locking

["Ion Alberdi (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IVY-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860959#comment-15860959 ] 

Ion Alberdi edited comment on IVY-654 at 2/10/17 9:20 AM:
----------------------------------------------------------

In case it can help other users facing a similar situation.

Using *Ivy 2.4.0* the issue can be solve with the following setting
http://ant.apache.org/ivy/history/latest-milestone/settings/caches.html

{code}
<caches resolutionCacheDir="${user.home}/.groovy/grapes/.cache/resolution" repositoryCacheDir="${user.home}/.groovy/grapes/.cache/repository" checkUpToDate="false" lockStrategy="artifact-lock-nio"/>
{code}

More precisely, that setting fixed the issue we had using Grape (through the @Grab decorator) in Groovy 2.4.7, (Grape relies on Ivy https://github.com/groovy/groovy-core/blob/master/src/main/groovy/grape/GrapeIvy.groovy#L345)

The full .groovy/grapeConfig.xml is:
{code}
<!-- Inspired from the default config: https://github.com/apache/groovy/blob/master/src/resources/groovy/grape/defaultGrapeConfig.xml -->
<ivysettings>
  <settings defaultResolver="downloadGrapes"/>
  <caches resolutionCacheDir="${user.home}/.groovy/grapes/.cache/resolution" repositoryCacheDir="${user.home}/.groovy/grapes/.cache/repository" checkUpToDate="false" lockStrategy="artifact-lock-nio"/>
  <resolvers>
    <chain name="downloadGrapes" returnFirst="true">
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]"/>
      </filesystem>
      <ibiblio name="nexus" m2compatible="true" root="http://nexus-par.criteo.prod/content/groups/criteodev"/>
    </chain>
  </resolvers>
</ivysettings>
{code}


was (Author: yetanotherion):
In case it can help other users facing a similar situation.

Using *Ivy 2.4.0* adding the following setting
http://ant.apache.org/ivy/history/latest-milestone/settings/caches.html

{code}
<caches resolutionCacheDir="${user.home}/.groovy/grapes/.cache/resolution" repositoryCacheDir="${user.home}/.groovy/grapes/.cache/repository" checkUpToDate="false" lockStrategy="artifact-lock-nio"/>
{code}

Fixed the issue we had using Grape (through the @Grab decorator) in groovy (Grape relies on Ivy https://github.com/groovy/groovy-core/blob/master/src/main/groovy/grape/GrapeIvy.groovy#L345)

The full grapeConfig.xml:
{code}
<!-- Inspired from the default config: https://github.com/apache/groovy/blob/master/src/resources/groovy/grape/defaultGrapeConfig.xml -->
<ivysettings>
  <settings defaultResolver="downloadGrapes"/>
  <caches resolutionCacheDir="${user.home}/.groovy/grapes/.cache/resolution" repositoryCacheDir="${user.home}/.groovy/grapes/.cache/repository" checkUpToDate="false" lockStrategy="artifact-lock-nio"/>
  <resolvers>
    <chain name="downloadGrapes" returnFirst="true">
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]"/>
      </filesystem>
      <ibiblio name="nexus" m2compatible="true" root="http://nexus-par.criteo.prod/content/groups/criteodev"/>
    </chain>
  </resolvers>
</ivysettings>
{code}

> Share cache with locking
> ------------------------
>
>                 Key: IVY-654
>                 URL: https://issues.apache.org/jira/browse/IVY-654
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Xavier Hanin
>            Assignee: Xavier Hanin
>             Fix For: 2.0.0-beta-1
>
>
> Currently it isn't possible use the same cache from multiple processes. This is a problem in some situations, especially for build servers, which have to use one cache per process, defeating some of the purpose of the cache. Adding an option allowing to use cache locking to ensure the repository cache can be used by concurrent build would be a nice improvement.
> To avoid degrading performance of local builds where the cache is not shared, this should only be an option.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)