Unfortunately, I think that detecting that you are offline or online is
something quiet difficult. So the user will have to pass some information
in his ant command line.
I think the most esthetic solution is to have a target offline like this :
<target name="offline" description="Run the build offline">
<property name="ivy.default.resolver" value="offline"/>
</target>
And then, when you configure ivy, use something like this :
<target name="-setup-ivy">
<property name="ivy.default.resolver" value="online"/>
<ivy:configure ....
</target>
By doing like this (instead of using a variable, you don't have to type
something like 'ant -Doffline= my_target' , but you can write 'ant offline
my_target'. Which is better (For the little story, it's actually Xavier
that gave me that tips).
Gilles
> -----Original Message-----
> From: Eric Crahen [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 22, 2006 3:29 PM
> To: [email protected]
> Subject: Re: Disconnected Development
>
> Thanks, thats very helpful.
> One thing I'm still interested in is possibly making the
> selection of the chain more automatic.
> Its easy enough to set a variable, but if it can be done for
> me that would just be all the better.
>
> On 12/21/06, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> >
> > To support offline build, I use some dedicated resolver
> chains. It
> > looks like this :
> >
> >
> > <cache name="cache">
> > <ivy
> > pattern="${ivy.cache.dir}/${ivy.cache.default.ivy.pattern}" />
> > <artifact
> > pattern="${ivy.cache.dir}/${ivy.cache.default.artifact.pattern}" />
> > </cache>
> > <filesystem name="local">
> > <ivy
> > pattern="${ivy.local.dir}/${ivy.local.default.ivy.pattern}" />
> > <artifact
> > pattern="${ivy.local.dir}/${ivy.local.default.artifact.pattern}" />
> > </filesystem>
> > <filesystem name="shared">
> > <ivy
> > pattern="${ivy.share.dir}/${ivy.shared.default.ivy.pattern}" />
> > <artifact
> > pattern="${ivy.share.dir}/${ivy.shared.default.artifact.pattern}" />
> > </filesystem>
> > <chain name="offline" returnFirst="true">
> > <resolver ref="local"/>
> > <resolver ref="cache"/>
> > </chain>
> > <chain name="online" returnFirst="true">
> > <resolver ref="local"/>
> > <resolver ref="shared"/>
> > </chain>
> >
> >
> > And my default conf is online or offline according to some
> ant variable.
> >
> >
> > NB: I think cache still requires a <typedef name="cache"
> > classname="fr.jayasoft.ivy.resolver.CacheResolver"/>. It is
> > distributed inside ivy, but I don't think it is documented yet
> > (previously it was not at least).
> >
> > Gilles
> >
> >
> > > -----Original Message-----
> > > From: Eric Crahen [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, December 21, 2006 7:25 PM
> > > To: [email protected]
> > > Subject: Re: Disconnected Development
> > >
> > > I'll have to look at using a retrieve task. And using the
> get seems
> > > like it could work.
> > > I was looking for something more build into the ant tasks so it
> > > would seem like less work to people who use ivy. Sometimes people
> > > can resist a tool if they see more than one line because it seems
> > > like "a lot of work" to them, which is somewhat silly in
> my opinion.
> > > I think I can make up some auxiallary tasks that delegate
> to the ivy
> > > tasks, or write some ant macros that give the appearance
> of a single
> > > line doing thing.
> > >
> > >
> > > On 12/21/06, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 12/21/06, Eric Crahen <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Maybe this has been answered, but let me explain what I
> > > am trying to do.
> > > > >
> > > > > I have some Ivy projects that I build while connected to
> > > my network
> > > > > and everything is fine.
> > > > > Now and again I need to unplug for various reasons and
> > > I'd like to
> > > > > still work. I have stuff in my cache from previous
> > > connected builds
> > > > > but I seem to have two issues to overcome.
> > > > >
> > > > > ---
> > > > >
> > > > > The first is that I use <ivy:configure url="..."/>. I do this
> > > > > because
> > > > its
> > > > > impractical to do otherwise.
> > > > > I have one configuration managed by someone for all
> my builds.
> > > > > It just sets up resolver chains and what not.
> > > > >
> > > > > When I disconnect I fail the configure and can't take
> > > advantage of
> > > > > anything that has been cached.
> > > > >
> > > > > Do you think it would be possible for ivy to cache
> configuration
> > > > > files
> > > > it
> > > > > downloads, so that
> > > > > when the network is unreachable it uses the cached
> version? Or
> > > > > better
> > > > yet,
> > > > > it always uses
> > > > > a cached version and just updates the cache in a
> > > background thread
> > > > > with each build - so that I won't have to wait for a
> > > network timeout
> > > > > on each build?
> > > >
> > > >
> > > > It's possible, but you can simply use the get task from ant
> > > and use a
> > > > <ivy:configure file="..."/>, and you'll be done without any
> > > modification
> > > > in
> > > > Ivy.
> > > >
> > > > ---
> > > > >
> > > > > The second is that I sometimes use revision patterns like
> > > "1.+'". When I
> > > > > use
> > > > > a pattern it seems
> > > > > the resolvers require a connection to query the server.
> > > If I use "1.0"
> > > > > then
> > > > > I will just take from the
> > > > > cache directly.
> > > > >
> > > > > Would it be possible for the resolvers to just query the
> > > local cache
> > > > when
> > > > > the network is down?
> > > >
> > > >
> > > > It's already possible to reuse the result of a last resolve
> > > (as documented
> > > > in the post resolve task page of the doc). You can also use an
> > > > ivyconf.xmlwhere you use a cache resolver, which will perform a
> > > > resolve from cache only (this would be easier with a
> > > > useCacheOnly="true" feature or
> > > something like
> > > > that, I agree). If you use the retrieve task then you can
> > > simply bypass
> > > > Ivy
> > > > altogether when you are offline, and use your retrieved lib
> > > dir as before.
> > > >
> > > > Xavier
> > > >
> > > > --
> > > > >
> > > > > - Eric
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > - Eric
> > >
> >
> >
>
>
> --
>
> - Eric
>
