[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Re: Component destination
|
Sounds like these settings could be kept in property files as they are more
about layout on a particular machine.
If there is a need to share the settings they can shared like other Eclipse
properties.
Just my 2c.
- henrik
"Thomas Hallgren" <thomas@xxxxxxx> skrev i meddelandet
news:endg7l$3n0$1@xxxxxxxxxxxxxxxxx...
> Hi,
> We need a better mechanism to control local preferences during
> materialization. One specific example is how to control where a component
> ends up on your local hard drive.We have a mechanism for this in the
> Materialize and Resolve wizard where you can override the default location
> but in Headless there is no such mechanism. Another example of such a
> preference is how to proceed when the designated location is not empty.
> That preference is kept in the CQUERY today.
>
> Historically, we've considered the CQUERY to be the place for local
> preferences. It has however migrated into a mechanism that provides an
> elaborate control the resolution phase and as such, it has also become
> something that is very likely to be shared. I sense that it's time to
> enforce a better separation of concern. The CQUERY should control the
> resolution phase and *only* that phase. Aspects that pertain to how things
> are materialized should be kept elsewhere.
>
> Things I see that should be moved into a new mechanism:
> 1. Designated component location (only in Wizard today)
> 2. What to do when a designated location is not empty (FAIL, OVERWRITE,
> REUSE)
> 3. Project name mapping (what to name a project in the local workspace if
> different from component name)
>
> Suggestions and ideas are very welcome.
>
> Regards,
> Thomas Hallgren
>