Re: [buckminster-dev] ResourceMap and properties

["Henrik Lindberg" <glashammer@xxxxxxxxxxx>]

Sounds fine, the idea is to create less work for developers - not more :)

One thought that crossed my mind, as complexity goes up regarding what is 
actually specified, I can imagine people getting into trouble with the many 
levels of indirection; RMAP pointing to RMAP etc. but now also taking 
"layered" parameters into account. The day when something does not 
materialize ok, I would want to know what actually happened - what 
parameters were overridden, and by what, and to be able to follow the flow - 
this so I can debug.

I am also thinking about materialization from a governance perspective. When 
looking at the Bill of Materials, shouln't I also be interested in from 
where the bits came from? (And naturally - if "official" settings have been 
overridden).

More specifically:

- Can I follow the materialization flow in a log somewhere?

- Can you put info about overridden parameters there?

- Does the BOM show info where the bits came from? (I know I have still to 
document the BOM :)

- Should the BOM contain info about overridden parameters?

- henrik

"Thomas Hallgren" <thomas@xxxxxxx> skrev i meddelandet 
news:mailman.3.1145553128.14830.buckminster-dev@xxxxxxxxxxx...
> I'm using Buckminster to materialize an assembly that doesn't use Eclipse 
> at all. It uses its own set if pre-compiled binaries for compilation. 
> Different platforms have a different set of buildtools and the 
> materialization must be able to cope with that (the buildtools are 
> components that take part of the materialization).
>
> At first I suggested use of federated resource maps, i.e. depending on 
> what platform you're on, you front the original rmap with one that finds 
> platform specific components. People in the project objected to this 
> because they find the rmap too complex. They use emacs or the like to 
> setup the build and they want to use Buckminster as a headless tool only. 
> Editing XML documents didn't appeal to them. Ideally, they'd like to have 
> a property file that they can use to control the process.
>
> The way the rmap is constructed today it can contain site specific 
> properties. The url's and other parameters for the providers are all 
> subject to property expansion. The sites are defined in the rmap itself. 
> We've had this up for debate before and now I think it's time to make some 
> changes. I propose two things:
>
> 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.
> 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.
> 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)
>
> Ideas? Suggestions?
>
> Regards,
> Thomas Hallgren
>