[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] ResourceMap and properties
|
1. Drop the site concept from the rmaps and more all property settings to
the top of the rmap. By doing so, the rmap can specify a set of default
properties.
Yes. For the benefit of others, I just to add some thoughts that we came up
with during earlier discussion: in practice an rmap can contain proprefs
that is *not* defined with defaults by the rmap itself. This is in effect
makes setting those props required 'somewhere else' (e.g. in the query). A
missing prop obviously generates an exception (however, consider that some
props might only be referenced from some searchPaths - i.e. as long as a
query uses search paths A, B and C all is well, but for D a 'required' prop
comes into play).
Let's not forget that there are a number of properties we can 'count on' -
i.e. standard system props like 'os.name' etc.
2. Add a URL to the cquery that appoints a properties file (simple Java
.properties format). Let the properties in this file override the ones
defined in the rmap.
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. This also alludes to Henriks concern of 'indirection layers' that raises
flexibility but adds complexity and possible backtracking issues. Generally
speaking, the BOM should (and do) obviously contain exactly the end
information used to 'get' things. Like Henrik's suggestion - an extension
would possibly be a dump of the 'flow' as well (what props were actually
overridden and how etc). Perhaps going a bit too far, but from a
tracking/debugging scenario possibly very useful...
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...
3. Remove the current 'site name' setting from the Buckminster preferences
and replace it with a URL that also appoints a property file. The
properties in this file will also override the rmap properties but they
too will be overridden by the properties appointed by the cquery.
We will then get four levels of properties, listed in descending order of
priority:
- System properties (as defined by the JVM and by -Dxxx=yyy parameters at
startup)
- Component Query specific properites (defined by a URL in the cquery)
- Site specific properties (defined by the URL in the Buckminster
preferences)
- Resource Map specific properties (defined in the rmap)
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
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.
ken1
