Re: [buckminster-dev] ResourceMap and properties

["Kenneth Ölwing" <kenneth@xxxxxxxxx>]

> One thought that crossed my mind, as complexity goes up regarding what is 
> actually specified, I can imagine people getting into trouble with the 
> many levels of indirection; RMAP pointing to RMAP etc. but now also taking 
> "layered" parameters into account. The day when something does not 
> materialize ok, I would want to know what actually happened - what 
> parameters were overridden, and by what, and to be able to follow the 
> flow - this so I can debug.

Just to touch on the subject again, yes, I'm also concerned about the 
layeredness, but I believe it's necessary to enable developer flexibility 
which is important. The other side of the coin, I think of it as the 'QA 
perspective', is hopefully taken care of other mechanism, chief among them 
the ability to run materializations etc with 'all overrides turned off'. 
Other mechanisms is also controlling BOM's etc.

I discuss this partially in the prev mail, but some more here...

> - Can I follow the materialization flow in a log somewhere?
> - Can you put info about overridden parameters there?


The only log I'm aware of at this time is the debugging log which is not 
useful enough and contain too much other stuff...though in principle adding 
a few log statements to the override mechanisms would enable this. Still, 
that log is too cumbersome. See below about a 'flow log'...

>
> - Does the BOM show info where the bits came from? (I know I have still to 
> document the BOM :)

The BOM does indeed show exactly where things originated (all references to 
repositories are broken down to as fixed specs as possible - for a P4 repo, 
a change number is used, in CVS a timestamp etc etc). All of this obviously 
hinges on dependable repositories...:-). An extension to this should/will 
(?) be manifests describing the contents of a given materialization - this 
will give a high degree of debugging capability in detecting errors even in 
such things. The manifest classes with generation, diffing, support for >1 
line ending convention & algorithm support is implemented. The only thing 
lacking from them is proper XML serialization/deserialization support (it 
currently uses a very simple linebased mechanism for that which works in the 
interim).

> - Should the BOM contain info about overridden parameters?

As mentioned, I'm also thinking if that would be a good thing. Considering 
the role of the BOM - such info should perhaps not be there (*how* the BOM 
came to be is different from *what* it is)...so maybe a separate 'flow log' 
of some kind would be more natural? Geared specifically to contain decision 
& override stuff. This would be mostly of interest for debugging and 
backtracking use I guess...

ken1