Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of xavier.hanin@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=JfwR+dnqCJ/GdJ+rv9l5YF/5AZiPnemb948a0ZuctwkGwyqIU/nhLNT+uMSzSVwovStXFvxesaoYvbRyYvxgxCcqR4B5g1pJMm3Laj99WYAhIziGp8/MViBj98p2SjpYHfggCoxObYL0Fy6HuL2gzg4DHv5w3aZHEOWF4z5in0I=
Message-ID: <635a05060612220844u6493ffeax8638ef4d05bb907b@mail.gmail.com>
Date: Fri, 22 Dec 2006 17:44:11 +0100
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Disconnected Development
In-Reply-To: <ed0c429e0612220749w47060f51qa6a1305ddefa0878@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_65800_9847375.1166805851981"
References: <1CCEA1ACF736B749B6FEE53168A6BF0001ACFB93@server1e>
	 <007401c725d9$cccdd180$3020a8c0@isabelteam.be>
	 <ed0c429e0612220749w47060f51qa6a1305ddefa0878@mail.gmail.com>

------=_Part_65800_9847375.1166805851981
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

It's not clear for me why you need one helper.xml per project? Why not just
one?

BTW, I'm not opposed to integrating cache management for ivyconf file, so
you can create an issue for that. But since it's not implemented for now I
think that using ant features should be ok for the moment.

Xavier
On 12/22/06, Eric Crahen <eric.crahen.lists@gmail.com> wrote:
>
> I think your right about that. The property really does seem the way to
> go.
> I tried out a couple
> methods of detecting the network being gone, but it adds seconds to the
> begining of each
> build.
>
> So this leads me back to other part of disconnected development. I have
> many
> projects which
> all share the same ivyconf.xml which is up on an HTTP server. Its the best
> way to do this for various
> reason. Now, as I mentioned before, the ivy:configure task fails when you
> use the "url" attribute
> and the url is not available.
>
> Xavier suggested just using the Ant get task to grab and cache the copy
> myself. Here is what the
> build.xml for this looks like:
>
> <?xml version="1.0" encoding="utf-8"?>
> <project name="Example">
>
> <!-- 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://www.google.com/pretend/your/ivyconf.xml/is/here"/>
>
> <!-- 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">
>    <get src="${ivy.config.xml}" dest="${ivy.config.cache.xml}"
> ignoreerrors="true" usetimestamp="true"/>
> </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>
>
> This really is *a lot* of build.xml code.
> Now, if the ivy:configure task would just do this caching for you, its *a
> lot* less
>
> <?xml version="1.0" encoding="utf-8"?>
> <project name="Example">
> <!-- -->
> <ivy:configure file="${ivy.config.cache.xml}"/>
> <!-- -->
>
> </project>
>
> What my goal is in all of this is to make it very easy for people writing
> a
> build.xml file
> for their project to do so. This means as little special build logic, and
> as
> little duplicated
> build logic as possible.
>
> More or less, I want to provide something like this. The reason is that it
> requires little
> effort for people to use Ivy, and it requires fewer changes when something
> important
> about the ivy configuration needs to change. I can update the server, and
> not have
> to coordinate changes with each the guy that wrote each build.xml and make
> sure he
> understand why, etc. The overall motivation, as silly as it might seem, is
> to make ivy
> and its correct use as invisible as possible and as simple to take
> advantage
> of as
> possible.
>
> <?xml version="1.0" encoding="utf-8"?>
> <project name="Example">
>
> <!-- Configure Ivy -->
> <ivy:configure url="http://myserver/ivyconf.xml"/>
> <ivy:resolve   useOrigin="true"/>
>
> <!-- Setup classpaths -->
> <ivy:cachepath pathid="compile.classpath"
>    useOrigin="true" conf="java.compile"/>
> <ivy:cachepath pathid="runtime.classpath"
>    useOrigin="true" conf="java.runtime"/>
> <ivy:cachepath pathid="test.classpath"
>    useOrigin="true" conf="java.test"/>
>
> <!-- Put your stuff here -->
>
> </project>
>
> Now, one thing I could do if the ivy:configure task doesn't cache the last
> good config
> at a url, is to put all that custom build.xml I first listed, along with
> the
> resolve.cachepath
> tasks into a local helper.xml. Each build would look like this:
>
> <?xml version="1.0" encoding="utf-8"?>
> <project name="Example">
>
> <import file="helper.xml"/>
> <!-- Put your stuff here you *just* have a couple classpaths -->
>
> </project>
>
> This makes a projects build.xml pretty simple, they add 1 line. The only
> trouble is
> that I now will have as many copies of the helper.xml as I do projects.
> And
> keeping
> those updated may be troublesome. Also people have to get one of these
> helper.xml's
> to begin with.
>
> Can anyone think of a better method than the helper.xml?
> What do people think of ivy:configure caching urls, could that be a better
> approach?
>
> One other sort of related note is that it would be nice to have an
> ant property ivy.use.origin that could be set once rather than setting
> it on each of the resolve and cachepath tasks.
>
> I think that if the ivy:configure tasks cached stuff and there were that
> one
> ant property that could be set once in my ivyconf.xml a build.xml might
> look like this:
>
> <?xml version="1.0" encoding="utf-8"?>
> <project name="Example">
>
> <!-- Configure Ivy -->
> <ivy:configure url="http://myserver/ivyconf.xml"/>
> <ivy:resolve/>
>
> <!-- Setup classpaths -->
> <ivy:cachepath pathid="compile.classpath"conf="java.compile"/>
> <ivy:cachepath pathid="runtime.classpath" conf="java.runtime"/>
> <ivy:cachepath pathid="test.classpath" conf="java.test"/>
>
> <!-- Put your stuff here -->
>
> </project>
>
> Which seems like the best solution to me. There is no special helper.xml,
> the parts of each
> build.xml that are repeated are very short, clear and simple to explain.
> The
> config is still
> centrally managed.
>
> What do you think?
>
>
> On 12/22/06, Gilles Scokart <gscokart@gmail.com> wrote:
> >
> >
> > 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:eric.crahen.lists@gmail.com]
> > > Sent: Friday, December 22, 2006 3:29 PM
> > > To: ivy-user@incubator.apache.org
> > > 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 <gscokart@gmail.com> 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:eric.crahen.lists@gmail.com]
> > > > > Sent: Thursday, December 21, 2006 7:25 PM
> > > > > To: ivy-user@incubator.apache.org
> > > > > 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 <xavier.hanin@gmail.com> wrote:
> > > > > >
> > > > > > On 12/21/06, Eric Crahen <eric.crahen.lists@gmail.com> 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
> > >
> >
> >
>
>
> --
>
> - Eric
>
>

------=_Part_65800_9847375.1166805851981--