|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
|
|
Disconnected resolutionHello,
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> -----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 resolutionOur 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. > |
|
|
|
|
|
Re: Disconnected resolutionTom,
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 > |
| Free embeddable forum powered by Nabble | Forum Help |