[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] ResourceMap and properties
|
I've done some more thinking about what needs to be present in a BOM. I think it is
important to strip information that is irrelevant. An abundance of properties, where a major
part of them perhaps never did participate, will just make things harder to debug. So I
propose the following instead:
We invent a property listener that gets notified when a property is accessed. The resolver
will install such a listener with the wrapper that we use for the system properties, the
site properties, and the property file appointed by the cquery. The listeners job is to
register all property accesses and record them with key, value, and origin (the origin being
"system", "site", or "cquery"). We then include this recording in the BOM instead of the
full set of system, site, and cquery properties.
The appointed resource map and cquery will still be included verbatim so some redundant
properties may exist (inlined in the cquery or defined as defaults in the rmap). The
alternative is to create stripped versions of those documents. My gut feeling is that that
would make debugging harder.
In addition to the above, the BOM also need to include the URL of the site property file to
be fully traceable.
- thomas
Kenneth Ölwing wrote:
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
Right. I agree with the list - any information we can think of that can
have an impact on choices and that we can easily extract should go into
a log of some kind.
I don't have any practical against storing it all in the BOM, so maybe
that is easiest. I was just thinking that to break things down and keep
them manageable etc, a sort of 'log' would contain a BOM as *one* of the
pieces. But this is just nitpicking...
ken1
