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