Re: [buckminster-dev] ResourceMap and properties

[Kenneth Ölwing <kenneth@xxxxxxxxx>]

> Inlined properties sounds like a good idea. What's your opinion on 
> priority between inlined and those found by URL?

Actually, I don't think I thought it through - I envisioned something like 
this:

<props>
   <prop key="a" value="b"/>
   <prop key="aa" value="bb"/>
   <extprops url="http://some.where/foo.props"/>
   <prop key="aaa" value="bbb"/>
   <extprops url="http://some.where.else/bar.props"/>
   <prop ...
   ...(continue intermixed)
</props>

But I realize that won't fly - because, as you say, there's a prio question 
between them...

I guess the only realistic idea is to add a sub point in the prop prio 
order:

1) rmap properties...but they can be overridden by:
2a) cquery inlined properties...but they can be overridden by:
2b) cquery url referenced properties...but they can be overridden by:
3) site-specific properties...but they can be overridden by:
4) 'java -Dsomeprop=somevalue' properties

> Not sure about 0-M URL's. Isn't that taking it a bit too far? Or should

No, agree. That's beyond need, and as it looks like mirrors in mirrors 
already, scratch that.

> 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.

I think this won't fly (yet) because you state 'you always know the origin 
of the query'. Unfortunately you don't...:-(. As we've seen, if you ask 
Eclipse to do File/Open File... you can indeed give an URL. BUT: the stupid 
thing gets downloaded locally first, and *then* our cquery parser comes in 
and get's handed a systemId to the local location. If so, we're hopelessly 
lost with using a relative URL from that :-(. But I may be wrong - maybe 
there's something else I'm unaware of here, that would be nice...

> Why can't QA simply use a 'clean' cquery if they so wish? Not sure I see 
> the benefit of an 'off'' switch.

I was thinking along the lines of that it's important for a paranoid QA to 
ensure no one has messed with their supposedly 'clean' cquery. Also, it 
would open for both Dev and QA to both use the *same* cquery URL, and slowly 
allow the cquery getting versioned such that it *eventually* is clean (in 
the meantime allow both paranoid and flexible use which works both 
directions - a dev can quickly try using it 'clean' and realize why QA is 
screaming :-). But then again, we've talked about cquery as something you 
potentially have 'many' of for various uses. Perhaps what I'm envisioning is 
the 'true official project cquery' and all others are developer managed etc.

Nah, I don't have a good rationale for going either way yet...we can 
definitively leave it on the backburner for now. It makes more sense to 
discuss later in a 'process' or 'best practices' context I think...