> But the point of Gump is that it tests the domain level build by building
> every part of the domain from scratch.

That assumes that the domain is evolving in synch, and is intended to be
released in synch.  It works great for a domain level project, but that's
not necessarily the case.

> a newcomer to the ideas of domain engineering I can totally
> subscribe to the principles of Gump, and seeing Avalon as a
> provider of domain commonalities, and James as an expression
> of variability, I can see how the domain level build testing
> of Gump would help accelerate the handling of James/Avalon issues.

>From that perspective, I could see two nightly builds: a domain level build,
and the other a build of James against the components that it is intended to
work with.

At some point a project with dependencies needs to freeze the dependencies.
You can't just take their latest CVS.

        --- Noel


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to