[jira] Commented: (IVY-361) Please add option for ivy:configure to cache remote files for diconnected development

["John Gill (JIRA)" <ji...@apache.org>]

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

John Gill commented on IVY-361:
-------------------------------

Ideally, it would be nice if ivy worked in much the same way as subversion. What I mean by that is that you "check out for files" (or in ivy's case, you download your dependencies), and then you can work off line until you want to update your dependencies (like you do an update in subversion), or publish your files (which is the equivalent of committing in svn).

So if <ivy:resolve> is like svn checkout and svn update, and <ivy:publish> is like svn commit, then maybe what we need is something else in ivy, like <ivy:cache> which is a resolve to the cache only.


> Please add option for ivy:configure to cache remote files for diconnected development
> -------------------------------------------------------------------------------------
>
>                 Key: IVY-361
>                 URL: https://issues.apache.org/jira/browse/IVY-361
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.4.1
>         Environment: All
>            Reporter: Eric Crahen
>
> (see the ivy-user@ archive for the complete discussion under the Disconnected Development thread)
> Doing disconnected development with an ivyconfig.xml that is stored on a server somewhere is quite a challenge. ivy:configure will fail immediately 
> when you use the url property and the network is unavailable. One way to get around this is to use an ant build file like this:
> <?xml version="1.0" encoding="utf-8"?>
> <!--
>  This is an expirement with creating a disconnected development
>  build. We still keep configuration in a central location, but
>  work from a local cache. As long as you build once connected,
>  you should be able to run disconnected.
>  -->
> <project
>   xmlns:ivy="antlib:fr.jayasoft.ivy.ant">
>   <!-- Prepare the location of the local cache of the remote file -->
>   <property name="ivy.config.cache" value="${user.home}${file.separator}.ivy${file.separator}config${file.separator}"/>
>   <property name="ivy.config.xml" value="http://myserver/ivyconf.xml"/>
>   <!-- Convert the URL to a safe filename -->
>   <pathconvert property="ivy.config.cache.name">
>     <path path="${file.separator}${ivy.config.xml}"/>
>     <filtermapper>
>       <replacestring from="${file.separator}" to="_"/>
>     </filtermapper>
>   </pathconvert>
>   <!-- The local cached file name -->
>   <property name="ivy.config.cache.xml" value="${ivy.config.cache}${ivy.config.cache.name}"/>
>   <mkdir dir="${ivy.config.cache}"/>
>   <!-- Start a background task to update the local cache -->
>   <parallel threadCount="1">
>     <daemons>
>       <get src="${ivy.config.xml}" dest="${ivy.config.cache.xml}" ignoreerrors="true" usetimestamp="true"/>
>     </daemons>
>   </parallel>
>   <!-- Wait for the local file to appear in the cache -->
>   <waitfor maxwait="3" maxwaitunit="second">
>     <available file="${ivy.config.cache.xml}"/>
>   </waitfor>
>   <!-- Fail the build if the remote config file could not be obtained and was not cached -->
>   <fail>
>     <condition><not><available file="${ivy.config.cache.xml}"/></not></condition>
>   </fail>
>   <ivy:configure file="${ivy.config.cache.xml}"/>
> </project>
> Which is quite a bit of ant build logic. If ivy:configure could simply cache the last known 
> copy of a remote file this could be reduced to :
> <?xml version="1.0" encoding="utf-8"?>
> <project
>   xmlns:ivy="antlib:fr.jayasoft.ivy.ant">
>   <ivy:configure useCache="true" url="http://myserver/ivyconf.xml"/>
> </project>
> which I think is a huge benefit to the end user. And makes getting to a disconnected build
> using ivy one step simpler for those who use a centralized ivyconfig.xml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.