| Re: [buckminster-dev] ResourceMap and properties |
Kenneth Ölwing wrote:
Ok. Some possible twists: maybe the query could just as well have 0-M prop key/values directly, as well as 0-M URL's to .properties files. The 'inline' properties have the benefit that they are 'right there'. I.e. as long as you have the 1) right cquery, and 2) the right rmap, you will find the right things; with 'external' properties that is another entity(ies) to keep track of.Inlined properties sounds like a good idea. What's your opinion on priority between inlined and those found by URL?
Not sure about 0-M URL's. Isn't that taking it a bit too far? Or should we go even further and say that for each URL you can also state if the file is required or optional? Again, complexity versus flexibility...
Another issue we touched briefly on the other day concerns URL's used in the query. Ideally, the URL's should be possible to be 'relative'. I know, there were some very hard problems with that (relative to what, and in what form etc). Just a point for the future - but some twist on this would surely be useful considering the 'project usage' I envisioned...I agree with this. The URL's should be relative. When resolving, you always now the origin of the query. The result of a resolve (the BOM) must probably contain expanded information (i.e. the contents of the rmap and all various property settings). So by then, the URL's are no longer an issue.
Umm, shouldn't it be the other way around regarding query/site specific props? The whole idea is to share the cquery among many, possibly dispersed, people but allow them to customize the actual settings used based on their site (i.e. overriding the settings in both the rmap and cquery). So my list would look like this (and for some reason I like to see it in ascending prio order...:-)1) rmap properties...but they can be overridden by: 2) cquery properties...but they can be overridden by: 3) site-specific properties...but they can be overridden by: 4) 'java -Dsomeprop=somevalue' properties
Right!
We also have to consider clearly any instances where and how it should be possible to 'turn off' any overrides, e.g. for a QA perspective where it's important to know that a materialization *only* uses data that is (hopefully) under close/secure (ideally even under CM control). This is partly the reason for the suggestion of inline props in the query - if an organization considers at least two things sacred, it ought to be the rmap and a certain query for a release.Why can't QA simply use a 'clean' cquery if they so wish? Not sure I see the benefit of an 'off'' switch.
- thomas