Hmm... That doesn't sound really appealing. We are already really
fighting with time to build. I'm still not convinced we don't have some
serious issues related to caching and TTL, but I haven't been able to
pin it down. But we are definitely spending WAY more time doing Ivy
resolution than I would like to see and I don't entirely know why that
is. In my mind, Ivy is a very simple set of tools that can be amazingly
difficult to use well. Getting it working isn't bad... getting it
working well seems to be alluding me.
On 11/2/09 3:01 PM, Joshua Tharp wrote:
No worries. I've been using Hudson and the plugin for several months. My
only complaint is that a module build can kick off a "build storm" as all
the downstream modules get scheduled, and then if any of those modules are
in turn dependencies, many modules can get placed back on the queue. If you
don't mind your build numbers increasing rather rapidly, and the build
machine cycles aren't in high demand otherwise, then it is a pretty good
solution.
On Mon, Nov 2, 2009 at 12:57 PM, Craig Setera<[email protected]> wrote:
Thanks. I've been picking up some of our build infrastructure, so I
apologize for not having a good background on all of this.
On 11/2/09 2:54 PM, Joshua Tharp wrote:
Have you looked at the Ivy plugin for Hudson? It does that already.
On Mon, Nov 2, 2009 at 12:51 PM, Craig Setera<[email protected]> wrote:
Has anyone used Ivy to map in reverse to find the modules that are
dependent on a particular module? Does anyone have any suggestions in
this
regard? What I'd like to be able to do is trigger a build of all
dependent
modules (in Hudson) when a module is changed to avoid things like
IncompatibleClassChangeError's from occurring.
Any suggestions appreciated.
Thanks,
Craig
