Skip to main content

[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
> 




Back to the top