Vindico == GumpNG (was Re: readying the cross-project build environment)

[Nicola Ken Barozzi <ni...@apache.org>]

Stefano Mazzocchi wrote:
>
> In my vision, forrestbot is automatic, just like Gump, it runs, build,
> copies and nags. Everyday. Helps you when you do the right thing and
> nags you when you do the bad thing, just like a wise boss :)
> 
> It's simple, effective and keeps up the social experiment concept that
> Gump started.
> 
> The only difference is that Gump doesn't affect anything directly (we
> don't build distributions with Gump or things like that), while Forrest
> will do both: perform the social test *and* do actual work on the
> project (by publishing their docos)
> 
> Is this difference important enough to force us to change the Gump
> model?
> 
> What do you think?

I've been discussing this topic for weeks on alexandria-dev (Gump), 
krysalis-dev (Centipede), partially here and with many friends :-)

We've come to the unanimous conclusion that there is a Gump-like work 
pattern that can be general enough to work with Gump and Forrest, a sort 
of big workspace job handler.
This has made me make a proposal of intent on the Gump list that has had 
a good reception.
I will refer to this new thing to as "Vindico", the name of one of the 
other Alexandria proposals.

There are still conceptual-architectural things to resolve that prevent 
me from making a solid-final proposal, and I would like to discuss it 
with you guys :-)

                      -oOo-
(warning: below is my current stream of consciousness;
  please read with an open mind)

Attatched is a very crude image of what I currently have in mind, with 
all the imperfections and doubts ;-)

Basically, Forrest and Gump could be just modules to plug into a generic 
   system that runs them on project definitions.

(on the lower part from left to right)
Sources are gotten from a repository, placed locally and "something" is 
run on them.
Then results are published somewhere.

As you see, this description can be used to define a build system: 
sources are copied in a "build" dir, an ant target is run, then results 
are put in a resulting dir under "build".

What makes this different? It works on *workspaces*, ie multiple projects.

Centipede has build components called cents already: junit cent, 
forrest.cent...

Yes, forrest.cent (still to upgrade, but the concept remains). I should 
be able to run forrest on my local docs during the build... why then 
duplicate Forrest as a .cent and as a bot?

Another step: on krysalis-dev, we have defined a buildmap, ie a big 
build descriptor that basically assembles macro build components.
Similarly as in Avalon stuff, Centipede becomes a Container of build 
Components for a local build.

Vindico would be a Container on a higher level.

So we would have this conceptual build-space:

Workspace (list of projects to build)
     |
Projectspace
     |
MiniProjectSpace (like Excalibur projects)


Forrest should be able to operate in all spaces... how to do it?

I think that we should keep Forrest, Gump, Centipede, Alexandria (source 
xref and Javadocs) in ProjectSpace, and collapse MiniProjectSpace and 
Projectspace in a single space; a Projectspace of many mimiprojects is 
in reality a Workspace of Projectspaces.

So we will have:
- workspace builders
- project builders

A workspace builder should be able to call project builders on each 
project in a workspace or on an aggregation of them, so it needs a 
dependency system, both between projectspaces and between build systems.

                   -oOo-

In essence, Vindico should be able to get the required sources and call 
Forrest (for docs), Gump (for fresh builds), Centipede and Maven (for 
daily builds), AlexandriaNG (for Javadocs) on each project and publish 
the results, all while keeping track of dependencies.

Any ideas?


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------