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 18:27:21 GMT
It would raise the burden on the user a bit, they'd have to add that extra
url.
Not a huge deal, but each little obstacle that can be removed is a great
thing.

I'm not sure how to do this sort of thing using Eclipse w/ Subclipse. With
that
tool you pick 1 svn url and check it out.

On 12/22/06, Xavier Hanin <xavier.hanin@gmail.com> wrote:
>
> 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.
>
>
> Ok, but isn't it acceptable to co the project and the helper?  You can
> even
> do it in one command only with svn:
> svn co http://svn/path/to/helper.xml http://svn/path/to/Project1
> Then your build.xml can reference the helper.xml, which has not to be
> maintained at several locations. But maybe this discussion would better go
> in the ant mailing list, we would get much more feedback on how to it in
> clean way.
>
> Xavier
>
> 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.xmland
> > > 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