[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] ResourceMap and properties
|
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...