Home » Archived » Buckminster » materializing using an MSPEC
| materializing using an MSPEC [message #1002318] |
Fri, 18 January 2013 11:48  |
|
Hi
by following a previous discussion by Eike,
http://www.eclipse.org/forums/index.php/t/247119/
and taking a look at CDO source materialization, I tried to offer
materialization with a remote MSPEC instead of a remote CQUERY; this has
the advantage, as far as I understand, to skip the manual creation of an
empty target platform in the workspace, am I right?
For instance, doing something like that:
<?xml version="1.0" encoding="UTF-8"?>
<mspec:mspec
xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
installLocation="${workspace.root}/target.platform"
materializer="p2"
name="build.mspec"
url="build.cquery">
<mspec:property key="target.os" value="*"/>
<mspec:property key="target.ws" value="*"/>
<mspec:property key="target.arch" value="*"/>
<mspec:property key="buckminster.download.source" value="true"/>
<mspec:mspecNode materializer="workspace"
filter="(buckminster.source=true)"/>
</mspec:mspec>
where I specify the install location of the p2 materialization, i.e.,
target platform.
In http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster
instead the creation of an empty target platform is required, and, most
of all, you get two duplicate git repositories (the first one where you
clone the initial repository to import the cquery and the second one
cloned during the resolution - since I might have cloned the repository
in a path different from the default one).
I was wondering why the MSPEC is not used...
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: materializing using an MSPEC [message #1002437 is a reply to message #1002318] |
Fri, 18 January 2013 15:18  |
|
Hi Lorenzo,
On 2013-01-18 12:48, Lorenzo Bettini wrote:
> Hi
>
> by following a previous discussion by Eike,
>
> http://www.eclipse.org/forums/index.php/t/247119/
>
> and taking a look at CDO source materialization, I tried to offer
> materialization with a remote MSPEC instead of a remote CQUERY; this has
> the advantage, as far as I understand, to skip the manual creation of an
> empty target platform in the workspace, am I right?
>
> For instance, doing something like that:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <mspec:mspec
> xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
> installLocation="${workspace.root}/target.platform"
> materializer="p2"
> name="build.mspec"
> url="build.cquery">
>
> <mspec:property key="target.os" value="*"/>
> <mspec:property key="target.ws" value="*"/>
> <mspec:property key="target.arch" value="*"/>
>
> <mspec:property key="buckminster.download.source" value="true"/>
>
> <mspec:mspecNode materializer="workspace"
> filter="(buckminster.source=true)"/>
> </mspec:mspec>
>
> where I specify the install location of the p2 materialization, i.e.,
> target platform.
>
> In http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster
> instead the creation of an empty target platform is required, and, most
> of all, you get two duplicate git repositories (the first one where you
> clone the initial repository to import the cquery and the second one
> cloned during the resolution - since I might have cloned the repository
> in a path different from the default one).
>
> I was wondering why the MSPEC is not used...
>
I don't understand what you're asking here really. The MSPEC declared
above determines that the target platform will end up in a directory
named 'target.platform' relative to the workspace. It doesn't say
anything at all about where the workspace is. And even if it did, that
wouldn't be the same as the location of the git repository. The
repository should typically be in $HOME/git and not the same as the
workspace.
If you get two clones, then that is because the location used when you
create your your first clone differs from the location specified in your
RMAP. This has nothing to do with the MSPEC.
- thomas
|
|
|
| Re: materializing using an MSPEC [message #1002606 is a reply to message #1002437] |
Fri, 18 January 2013 23:23 |
|
Hi Thomas
I realized my post was really confusing because I was asking two
questions at once :)
I was just trying to find a very fast way to let contributors
materialize sources of my projects.
Let me try again :)
In http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster you
say to first create a new target platform with an empty directory and
then start the materialization (to make sure not to mix things from the
running platform, right?).
In order to avoid requiring to prepare manually such empty target
platform, one could provide an MSPEC which specifies the install
location, e.g.,
<?xml version="1.0" encoding="UTF-8"?>
<mspec:mspec
xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
installLocation="${workspace.root}/target.platform"
materializer="p2"
name="build.mspec"
url="build.cquery">
<mspec:property key="target.os" value="*"/>
<mspec:property key="target.ws" value="*"/>
<mspec:property key="target.arch" value="*"/>
<mspec:property key="buckminster.download.source" value="true"/>
<mspec:mspecNode materializer="workspace"
filter="(buckminster.source=true)"/>
</mspec:mspec>
this way, during the materialization, p2 will materialize starting from
an empty target platform automatically, am I right?
I mean, to have a working workspace, one could even just provide the
contributors with an URL to a remote MSPEC and that's all, and tell them
to import that right away (no need to prepare the empty target
platform), is that right?
Concerning the CQUERY approach, I was wondering why not providing the
URL to the remote CQUERY, instead of first manually cloning the
repository, then import the releng project and then start the
materialization (as reported here:
http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster)?
I mean why don't you just say to open this remote CQUERY in the workspace?
http://git.eclipse.org/c/buckminster/buckminster.git/plain/org.eclipse.buckminster.releng/build.cquery
Has the solution of remote CQUERY some drawbacks?
In general, has the solution of the MSPEC some drawbacks?
(I end up with two clones just because I first cloned the repository
into another location but that is my problem, so please ignore that :)
thanks in advance
cheers
Lorenzo
On 01/18/2013 04:18 PM, Thomas Hallgren wrote:
> Hi Lorenzo,
>
> On 2013-01-18 12:48, Lorenzo Bettini wrote:
>> Hi
>>
>> by following a previous discussion by Eike,
>>
>> http://www.eclipse.org/forums/index.php/t/247119/
>>
>> and taking a look at CDO source materialization, I tried to offer
>> materialization with a remote MSPEC instead of a remote CQUERY; this has
>> the advantage, as far as I understand, to skip the manual creation of an
>> empty target platform in the workspace, am I right?
>>
>> For instance, doing something like that:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <mspec:mspec
>> xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
>> installLocation="${workspace.root}/target.platform"
>> materializer="p2"
>> name="build.mspec"
>> url="build.cquery">
>>
>> <mspec:property key="target.os" value="*"/>
>> <mspec:property key="target.ws" value="*"/>
>> <mspec:property key="target.arch" value="*"/>
>>
>> <mspec:property key="buckminster.download.source" value="true"/>
>>
>> <mspec:mspecNode materializer="workspace"
>> filter="(buckminster.source=true)"/>
>> </mspec:mspec>
>>
>> where I specify the install location of the p2 materialization, i.e.,
>> target platform.
>>
>> In http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster
>> instead the creation of an empty target platform is required, and, most
>> of all, you get two duplicate git repositories (the first one where you
>> clone the initial repository to import the cquery and the second one
>> cloned during the resolution - since I might have cloned the repository
>> in a path different from the default one).
>>
>> I was wondering why the MSPEC is not used...
>>
> I don't understand what you're asking here really. The MSPEC declared
> above determines that the target platform will end up in a directory
> named 'target.platform' relative to the workspace. It doesn't say
> anything at all about where the workspace is. And even if it did, that
> wouldn't be the same as the location of the git repository. The
> repository should typically be in $HOME/git and not the same as the
> workspace.
>
> If you get two clones, then that is because the location used when you
> create your your first clone differs from the location specified in your
> RMAP. This has nothing to do with the MSPEC.
>
> - thomas
>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: materializing using an MSPEC [message #1003468 is a reply to message #1002606] |
Mon, 21 January 2013 09:50 |
|
On 2013-01-19 00:23, Lorenzo Bettini wrote:
>
> In http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster you
> say to first create a new target platform with an empty directory and
> then start the materialization (to make sure not to mix things from the
> running platform, right?).
>
Yes.
> In order to avoid requiring to prepare manually such empty target
> platform, one could provide an MSPEC which specifies the install
> location, e.g.,
>
> <?xml version="1.0" encoding="UTF-8"?>
> <mspec:mspec
> xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
> installLocation="${workspace.root}/target.platform"
> materializer="p2"
> name="build.mspec"
> url="build.cquery">
>
> <mspec:property key="target.os" value="*"/>
> <mspec:property key="target.ws" value="*"/>
> <mspec:property key="target.arch" value="*"/>
>
> <mspec:property key="buckminster.download.source" value="true"/>
>
> <mspec:mspecNode materializer="workspace"
> filter="(buckminster.source=true)"/>
> </mspec:mspec>
>
> this way, during the materialization, p2 will materialize starting from
> an empty target platform automatically, am I right?
>
Yes.
> I mean, to have a working workspace, one could even just provide the
> contributors with an URL to a remote MSPEC and that's all, and tell them
> to import that right away (no need to prepare the empty target
> platform), is that right?
>
Yes.
> Concerning the CQUERY approach, I was wondering why not providing the
> URL to the remote CQUERY, instead of first manually cloning the
> repository, then import the releng project and then start the
> materialization (as reported here:
> http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster)?
>
> I mean why don't you just say to open this remote CQUERY in the workspace?
> http://git.eclipse.org/c/buckminster/buckminster.git/plain/org.eclipse.buckminster.releng/build.cquery
>
> Has the solution of remote CQUERY some drawbacks?
>
Yes. You get less control over branches. Assume for instance that you
want to:
1. Clone the repostiory
2. Select a branch other than master
3. Run resolve/materialize
Buckminster will use the 'current' branch by default. This means that
you can allow CI systems (Jenkins for instance) to clone and check out a
specific branch first and then have Buckminster run the resolution using
that branch. All of that happens without the need of specifying a branch
in the cquery.
> In general, has the solution of the MSPEC some drawbacks?
>
Same as for cquery with the addition that when you run in a CI system,
the initial creation of a target platform is often configured as part of
the CI process. If that happens, or when the intended scenario is to use
defaults, then the mspec becomes an unnecessary artifact.
- thomas
|
|
|
| Re: materializing using an MSPEC [message #1003943 is a reply to message #1003468] |
Tue, 22 January 2013 09:44 |
|
On 01/21/2013 10:50 AM, Thomas Hallgren wrote:
>> Concerning the CQUERY approach, I was wondering why not providing the
>> URL to the remote CQUERY, instead of first manually cloning the
>> repository, then import the releng project and then start the
>> materialization (as reported here:
>> http://wiki.eclipse.org/Extending_or_Contributing_to_Buckminster)?
>>
>> I mean why don't you just say to open this remote CQUERY in the
>> workspace?
>> http://git.eclipse.org/c/buckminster/buckminster.git/plain/org.eclipse.buckminster.releng/build.cquery
>>
>>
>> Has the solution of remote CQUERY some drawbacks?
>>
> Yes. You get less control over branches. Assume for instance that you
> want to:
>
> 1. Clone the repostiory
> 2. Select a branch other than master
> 3. Run resolve/materialize
>
> Buckminster will use the 'current' branch by default. This means that
> you can allow CI systems (Jenkins for instance) to clone and check out a
> specific branch first and then have Buckminster run the resolution using
> that branch. All of that happens without the need of specifying a branch
> in the cquery.
OK!
>
>> In general, has the solution of the MSPEC some drawbacks?
>>
> Same as for cquery with the addition that when you run in a CI system,
> the initial creation of a target platform is often configured as part of
> the CI process. If that happens, or when the intended scenario is to use
> defaults, then the mspec becomes an unnecessary artifact.
OK, I see: in CI you start with an empty target platform anyway.
Thus, an MSPEC might be used to have a very quick way of materializing
stuff in the IDE with defaults (and no need to prepare an empty target
platform).
I guess, one can even distribute different MSPECs for different
configurations by setting in the MSPEC some properties (e.g., the
property for the git branch, the URL for Eclipse repository - juno or
kepler, etc.)
thanks again Thomas
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:43:52 GMT 2024
Powered by FUDForum. Page generated in 0.03253 seconds |
] 
Search
Help
Register
Login
Home
