Proposal: simple materialization outside the workspace [message #704428] |
Thu, 28 July 2011 16:04  |
Eclipse User |
|
|
|
When materializing a CQuery, by default Buckminster checks out source components into the workspace directory. To override this this you need an mspec (my description of how to do it is in this forum at http://www.eclipse.org/forums/index.php/t/215455/), but the process is a bit clunky.
I would like to propose a small enhancement to the way Buckminster works. When currently we materialize to ${workspace.root}, materialize to ${location.root} (or some similar name) (if not set, ${location.root} would default to ${workspace.root}).
This provides a simple way to materialize in a directory that is not the same as the workspace directory, simply by adding a property to the RMap, or specifying it in that CQuery (or on the command line, if headless). Of course, this only handles the simplest case, where everything that was previously in the workspace is now elsewhere. An mspec is still required for more complex materialization layouts.
It could be argued that it is the job of the mspec to specify where materialization happens. However, for the git provider type, you already have to specify where the local clone is to be made, and you can already do exactly what I propose. However, for Subversion (and other provider types), this is not currently doable without using an mspec.
What do folks think? Doable? Worth doing? Consistent with where Buckminster is going?
Thanks
|
|
|
Re: Proposal: simple materialization outside the workspace [message #704548 is a reply to message #704428] |
Thu, 28 July 2011 19:18   |
Eclipse User |
|
|
|
We have discussed doing the same for all repositories (that Buckminster
does for git, as there are several advantages) but the required changes
seemed to be quite extensive (and IIRC there were a couple of cases
where things got messy). We do not however have resources to spend on
such an implementation, but would be happy to help someone that would
like to take it on. (OTOH, you never know what Thomas is up to when he
is on vacation ;)
I know it is not a solution, but everyone seems to be migrating to git ;)
Regards
- henrik
On 7/28/11 6:04 PM, Matthew Webber wrote:
> When materializing a CQuery, by default Buckminster checks out source
> components into the workspace directory. To override this this you need
> an mspec (my description of how to do it is in this forum at
> http://www.eclipse.org/forums/index.php/t/215455/), but the process is a
> bit clunky.
>
> I would like to propose a small enhancement to the way Buckminster
> works. When currently we materialize to ${workspace.root}, materialize
> to ${location.root} (or some similar name) (if not set, ${location.root}
> would default to ${workspace.root}).
>
> This provides a simple way to materialize in a directory that is not the
> same as the workspace directory, simply by adding a property to the
> RMap, or specifying it in that CQuery (or on the command line, if
> headless). Of course, this only handles the simplest case, where
> everything that was previously in the workspace is now elsewhere. An
> mspec is still required for more complex materialization layouts.
>
> It could be argued that it is the job of the mspec to specify where
> materialization happens. However, for the git provider type, you already
> have to specify where the local clone is to be made, and you can already
> do exactly what I propose. However, for Subversion (and other provider
> types), this is not currently doable without using an mspec.
>
> What do folks think? Doable? Worth doing? Consistent with where
> Buckminster is going?
>
> Thanks
>
>
|
|
|
Re: Proposal: simple materialization outside the workspace [message #704906 is a reply to message #704548] |
Fri, 29 July 2011 07:43  |
Eclipse User |
|
|
|
Thanks henrik, at least that confirms that my idea was not completely silly.
I understand that you don't have the resources to do everything, and that this is not a priority - I'm just grateful for what you have done with Buckminster - it's changing the way we do things. I know Thomas likes to say "patches always welcome", but I'm not even a Java person, just the guy was looks after our build environment, so I can't help you there.
And yes, we are moving to git - though not all of our code.
Matthew
|
|
|
Powered by
FUDForum. Page generated in 0.04985 seconds