ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: building only whats necessary with Ivy
Date Tue, 18 Sep 2007 06:32:26 GMT
On 9/17/07, David Taylor <dtayl@stanford.edu> wrote:
>
> The old IvyCruise page on the JayaSoft site points to IvyPublisher as
> the successor to IvyCruise. But on IvyPublisher's SourceForge site, I
> see no activity since its initial release a year ago.
>
> Why no mention of IvyPublisher in this discussion? Did IvyPublisher
> follow IvyCruise to IvyHeaven?


I don't really know what is the status of IvyPublisher, but the problem with
IvyPublisher is that it doesn't ensure the correct order of project builds:
if A depends on B and you check in a modification on both A and B at
approximately the same time, you may end up with A being built before B
(resulting in an error if A depends on a modification of B), then being
built again after B.

Xavier

dtayl
>
> ivy-user-digest-help@incubator.apache.org wrote:
> >
> > Subject:
> > Re: building only whats necessary with Ivy
> > From:
> > "Xavier Hanin" <xavier.hanin@gmail.com>
> > Date:
> > Thu, 13 Sep 2007 15:37:06 +0200
> > To:
> > ivy-user@incubator.apache.org
> >
> >
> > This would be a good question for the xooctory user list :-) More
> comments
> > below.
> >
> > On 9/13/07, Stephan Zeissler (KUTTIG) <stephan.zeissler@kuttig.com>
> wrote:
> >
> >> I don't think thats a feature of Ivy, more a feature of xooctory. The
> CI
> >> server may parse the ivy.xml files and build a dependency tree from
> >> this. So when your projects depends on a library and you build a new
> >> version of the lib, all dependent projects get rebuild, too.
> >>
> >
> >
> > That's exactly what xooctory does (or is about to do, since this feature
> is
> > still in developement). Basically some continuous integration servers do
> not
> > implement project dependencies at all, and recommend to build your whole
> > codebase at once whenever one module in your app change (this is what
> has
> > been recommended with cruisecontrol for a long time). This does not
> scale
> > very well, and you happen to rebuild and retest your whole application
> only
> > when a very small subset is changed. Hence some CI servers implement
> project
> > dependencies, so that you create one project in your server per module
> in
> > your app, describe their dependencies, then the server takes care of
> > rebuilding the right modules depending on your modifications. But then
> when
> > you a dependency manager like Ivy, you still have to maintain your
> > dependencies in your CI server by hand to keep them in sync with your
> > metadata. So the idea is to make the CI server aware of metadata
> available
> > in your modules. That's what the IvyCruise plugin tried to achieve a
> long
> > time ago, but the CC architecture didn't make that easy. So that's what
> > xooctory will achieve pretty soon.
> >
> > As i dont know xooctory, I dont know how it determines, what has
> >
> >> changed, but from hudson I know that you can e.g. pull a scm repository
> >> (svn,cvs,..) regularly or start a build via the invocation of an URL.
> >> But all this is part of the CI server, not Ivy.
> >>
> >
> >
> > Indeed. The singularity is that Xooctory considers module dependencies
> as
> > first class citizens in the CI process, as the SCM is. Hudson has pretty
> > good support of project dependencies, but you still need to maintain
> them by
> > hand as far as I know (at least it was the case when I started the
> xooctory
> > project some months ago).
> >
> > Xavier
> >
> > - Stephan
> >
> >> bhatia schrieb:
> >>
> >>> On the xooctory site, I read this:
> >>>
> >>> "leveraging Ivy to manage the dependencies between the modules, and
> >>>
> >> rebuild
> >>
> >>> exactly what is necessary, in the correct order, blocking builds when
> a
> >>> dependency is currently building, and so on"
> >>>
> >>> Can someone provide more inputs/ideas on how to rebuild exactly what
> is
> >>> necessary using Ivy ? What are the (best) practices you use to
> determine
> >>> what has changed ?
> >>>
> >>> thanks
> >>>
> >>>
> >
> >
> >
> >
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

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