ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Crahen" <eric.crahen.li...@gmail.com>
Subject Re: Disconnected Development
Date Fri, 22 Dec 2006 17:11:31 GMT
By many copies I mean 1 per project

On 12/22/06, Eric Crahen <eric.crahen.lists@gmail.com> wrote:
>
> Well, each project would need to build on my own.
> I'd need to be able to do something like
>
> svn co http://svn/path/to/Project1
>
> and get everything thing I need to build that package.
>
> svn co http://svn/path/to/Project2
>
> and get everything thing I need to build that package.
>
> So that helper.xml would need to be present in each package
> just like the build.xml would need to be present in each package.
>
> The build.xml would be importing the helper.xml and I can't
> keep on the network since the goal is disconnected development
> and I since I'd like that one command to check out source give you
> the code and all that is needed to build it, I'd have many copies.
>
>
> On 12/22/06, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> >
> > 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.xmlmight
> > > 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
> > >
> > >
> >
> >
>
>
> --
>
> - Eric




-- 

- Eric

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message