[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] ResourceMap and properties
|
Kenneth Ölwing wrote:
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.
Lot's of room for cool GUI improvements here. First and foremost a good
RMAP editor that is able to handle RMAP federations. Other things that
spring to mind is a graphical representation of the result of a
transitive resolve with clickable nodes that show information about
decisions that where made.
- 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...
The BOM must contain info about all bits and pieces and their origin.
Simply put, I think that aside from the current set of fixed repository
designators it will also contain a snapshot of:
1) The system properties
2) The site properties
3) Property file(s) appointed by the cquery
4) The appointed resource map(s)
5) The cquery
Item #3 and #4 ties back to the question of relative URL's in the query.
I believe that A snapshot of the actual data makes it a non-issue to
have that.
We already store all this information in the workspace meta-data but our
current BOM needs some additional work
- thomas
