Disconnected resolution

View: New views
5 Messages — Rating Filter:   Alert me  

Disconnected resolution

by Craig Setera-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

We are still getting our heads around all that Ivy offers and trying to
apply it to our build infrastructure along with Hudson.  In general,
things are working pretty well for us, but while on a flight last week,
I found that despite having a fully primed resolution cache, that
resolution still wanted to call out and check the cache, causing build
failures while disconnected.  It was my understanding that the caching
should have been able to take care of this, but obviously we aren't
doing something correctly.  I'm hoping someone can  shed some light on
what we might be doing wrong.  Our Ivy settings file is embedded below.

Thanks for any insights,
Craig

<ivysettings>

<!--  Set the default settings -->
<settings defaultResolver="mfoundry" defaultConflictManager="all" />

<!--  Read in the properties -->
<properties file="${ivy.settings.dir}/ivy-builder-settings.properties" />

<!-- Configure the SVN Resolver support -->
<property name="ivn.svnresolver.home"
value="${ivy.settings.dir}/lib/ivy-svnresolver-2.0.0" />
<classpath file="${ivn.svnresolver.home}/ivysvnresolver.jar"/>
<classpath file="${ivn.svnresolver.home}/svnkit.jar"/>
<classpath
file="${ivn.svnresolver.home}/ivy-svnresolver-2.0.0/trilead.jar"/>
<typedef name="svn"
classname="fm.last.ivy.plugins.svnresolver.SvnResolver" />

<caches>
<cache name="adhoc-cache" basedir="${ivy.adhoc.cache}" useOrigin="true"
defaultTTL="${mf.ivy.local.cache.ttl}" />
<cache name="local-cache" basedir="${ivy.local.cache}" useOrigin="true"
defaultTTL="${mf.ivy.local.cache.ttl}" />
</caches>

<resolvers>

<filesystem name="adhoc" cache="adhoc-cache">
<ivy
pattern="${ivy.adhoc.repository}/[organisation]/[module]/[revision]/[module]-[revision]-ivy.xml"
/>
<artifact
pattern="${ivy.adhoc.repository}/[organisation]/[module]/[revision]/[type]s/[artifact]-[revision].[ext]"
/>
</filesystem>

<filesystem name="local" cache="local-cache">
<ivy
pattern="${ivy.local.repository}/[organisation]/[module]/[revision]/[module]-[revision]-ivy.xml"
/>
<artifact
pattern="${ivy.local.repository}/[organisation]/[module]/[revision]/[type]s/[artifact]-[revision].[ext]"
/>
</filesystem>

<svn name="artifacts" repositoryRoot="${ivy.svn.repo.path}"
userName="${svn.username}" userPassword="${svn.password}"
binaryDiff="false">
<ivy
pattern="artifacts/[organisation]/[module]/[revision]/[module]-[revision]-ivy.xml"/>
<artifact
pattern="artifacts/[organisation]/[module]/[revision]/[type]s/[artifact]-[revision].[ext]"/>
</svn>

<svn name="snapshots" repositoryRoot="${ivy.svn.repo.path}"
userName="${svn.username}" userPassword="${svn.password}"
binaryDiff="false">
<ivy
pattern="snapshots/[organisation]/[module]/[revision]/[module]-[revision]-ivy.xml"/>
<artifact
pattern="snapshots/[organisation]/[module]/[revision]/[type]s/[artifact]-[revision].[ext]"/>
</svn>

<!--
         Chain of repositories used for retrieval only. The repositories
are searched in
         order with the first match ending the search. This is a good
starting point for
         development use as the search list is from more private to more
public.
         -->
<chain name="mfoundry" returnFirst="true">
<resolver ref="adhoc"/>
<resolver ref="local"/>
<resolver ref="snapshots"/>
<resolver ref="artifacts"/>
</chain>

</resolvers>
</ivysettings>


RE: Disconnected resolution

by carltonb :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> -----Original Message-----
> From: Craig Setera [mailto:craig@...]
> Sent: Monday, October 26, 2009 9:21 AM
> To: ivy-user@...
> Subject: Disconnected resolution
>
> Hello,
>
> We are still getting our heads around all that Ivy offers and trying
to
> apply it to our build infrastructure along with Hudson.  In general,
> things are working pretty well for us, but while on a flight last
week,
> I found that despite having a fully primed resolution cache, that
> resolution still wanted to call out and check the cache, causing build
> failures while disconnected.  It was my understanding that the caching
> should have been able to take care of this, but obviously we aren't
> doing something correctly

If your filesystem resolvers are network-mounted, they will not work
offline because you have useOrigin=true on the caches they are
referencing.   Not sure about the svn resolver.  


***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

Re: Disconnected resolution

by Craig Setera-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Our resolvers are not network-mounted.  Those file system resolvers are
truly local.  What can we do to keep from checking the SVN resolvers in
disconnected mode?

On 10/26/09 9:43 AM, Carlton Brown wrote:

>> -----Original Message-----
>> From: Craig Setera [mailto:craig@...]
>> Sent: Monday, October 26, 2009 9:21 AM
>> To: ivy-user@...
>> Subject: Disconnected resolution
>>
>> Hello,
>>
>> We are still getting our heads around all that Ivy offers and trying
>>      
> to
>    
>> apply it to our build infrastructure along with Hudson.  In general,
>> things are working pretty well for us, but while on a flight last
>>      
> week,
>    
>> I found that despite having a fully primed resolution cache, that
>> resolution still wanted to call out and check the cache, causing build
>> failures while disconnected.  It was my understanding that the caching
>> should have been able to take care of this, but obviously we aren't
>> doing something correctly
>>      
> If your filesystem resolvers are network-mounted, they will not work
> offline because you have useOrigin=true on the caches they are
> referencing.   Not sure about the svn resolver.
>
>
> ***CONFIDENTIALITY NOTICE and DISCLAIMER***
> This message and any attachment are confidential and may be
> privileged or otherwise protected from disclosure and solely for
> the use of the person(s) or entity to whom it is intended. If you
> have received this message in error and are not the intended
> recipient, please notify the sender immediately and delete this
> message and any attachment from your system. If you are not the
> intended recipient, be advised that any use of this message is
> prohibited and may be unlawful, and you must not copy this
> message or attachment or disclose the contents to any other person.
>    

Parent Message unknown Re: Disconnected resolution

by Tom Widmer-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Craig Setera wrote:

> Hello,
>
> We are still getting our heads around all that Ivy offers and trying to
> apply it to our build infrastructure along with Hudson.  In general,
> things are working pretty well for us, but while on a flight last week,
> I found that despite having a fully primed resolution cache, that
> resolution still wanted to call out and check the cache, causing build
> failures while disconnected.  It was my understanding that the caching
> should have been able to take care of this, but obviously we aren't
> doing something correctly.  I'm hoping someone can  shed some light on
> what we might be doing wrong.  Our Ivy settings file is embedded below.
>
> Thanks for any insights,
> Craig

When running disconnected, you could set:
ivy.cache.ttl.default
to "eternal". This means that cached dynamic revisions should not be
re-checked at all. You can also do this explicitly using a cache element:

<cache name="remote-cache" useOrigin="false" blah>
   <ttl duration="${remote.ttl.duration}"/>
</cache>

(use this cache for your svn resolvers)

Now your ant script can somehow arrange to set remote.ttl.duration to
"eternal" if you are offline, or to 0ms (or similar) if you are online.

Tom


Re: Disconnected resolution

by Craig Setera-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Tom,

Thanks much for the "eternal" reference.  That is a good thing to note
and I will give it a try.

With that said, I had thought we had set our behavior such that we have
a 12 hour TTL for the "remote" caches.  Despite that, it still seems to
take a *very* long time to resolve and appears to be going back out the
SVN resolvers.  I will take a look at the Ant debug output once again to
see what is going on, but I'm wondering if there is something else I
might be missing that is causing this behavior?

Thanks,
Craig

On 10/27/09 6:17 AM, Tom Widmer wrote:

> Craig Setera wrote:
>> Hello,
>>
>> We are still getting our heads around all that Ivy offers and trying
>> to apply it to our build infrastructure along with Hudson.  In
>> general, things are working pretty well for us, but while on a flight
>> last week, I found that despite having a fully primed resolution
>> cache, that resolution still wanted to call out and check the cache,
>> causing build failures while disconnected.  It was my understanding
>> that the caching should have been able to take care of this, but
>> obviously we aren't doing something correctly.  I'm hoping someone
>> can  shed some light on what we might be doing wrong.  Our Ivy
>> settings file is embedded below.
>>
>> Thanks for any insights,
>> Craig
>
> When running disconnected, you could set:
> ivy.cache.ttl.default
> to "eternal". This means that cached dynamic revisions should not be
> re-checked at all. You can also do this explicitly using a cache element:
>
> <cache name="remote-cache" useOrigin="false" blah>
> <ttl duration="${remote.ttl.duration}"/>
> </cache>
>
> (use this cache for your svn resolvers)
>
> Now your ant script can somehow arrange to set remote.ttl.duration to
> "eternal" if you are offline, or to 0ms (or similar) if you are online.
>
> Tom
>