ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ion Alberdi (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IVY-654) Share cache with locking
Date Fri, 10 Feb 2017 09:20:41 GMT

    [ 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)

Mime
View raw message