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:08:23 GMT
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.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
> >
> >
>
>


-- 

- Eric

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