| Using workspace relative target definition [message #514111] |
Fri, 12 February 2010 13:17  |
 Matthias Kappeller
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi,
I have defined a mspec to materialize some components into the target platform and some into the workspace.
<?xml version="1.0" encoding="UTF-8"?>
<mspec:mspec xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0" materializer="p2" installLocation="${targetPlatformPath}" name="myMSpec" url="a.cquery" conflictResolution="UPDATE">
<mspec:mspecNode namePattern="^app1(\..+)?" componentType="osgi.bundle" materializer="workspace"/>
</mspec:mspec>
The 'targetPlatformPath' Property is defined in the cquery.
<?xml version="1.0" encoding="UTF-8"?>
<cq:componentQuery xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0" resourceMap="http://svn/trunk/rmap/a.rmap">
<cq:rootRequest name="app1.component.a" componentType="buckminster"/>
<cq:property key="targetPlatformPath" value="${workspace.root}/targetPlatform"/>
</cq:componentQuery>
After materialization in Eclipse the target platform can be set by using a target definition.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.5"?>
<target name="WS4">
<locations>
<location path="${workspace_loc}/targetPlatform" type="Directory"/>
</locations>
</target>
Because of all relative paths this works great inside Eclipse.
As the next step i would take the mspec and build it with buckminster headless.
I've configured hudson:
resolve http://svn/trunk/mspec/a.mspec
importtargetdefinition -A http://svn/trunk/target/a.target
build
And it doesn't work as expected 
The first "mystery" is, that the property defined in the cquery is not choosen. The components are materialized into BUCKMINSTER_HEADLESS_INSTALL_LOCATION/${targetPlatformPath}.
After setting the property 'targetPlatformPath' in Hudson to '${WORKSPACE}/targetPlatform' the components have been materialized to the right directory.
But it seems to be that the target definition couldn't find this directory, because the other components can not find the required bundles.
What am I doing wrong? Am I not able to choose workspace relative paths within buckminster headless?
Regards,
Matthias
[Updated on: Fri, 12 February 2010 13:18] Report message to a moderator |
|
|
| Re: Sharing Target Definition [message #514126 is a reply to message #514111] |
Fri, 12 February 2010 09:12  |
|
Hi Matthias,
I think you should remove the installLocation in the mspec altogether. That will make the p2 materializer use the
currently active target platform. It is also wise to define the active target platform before you import (resolve and
materialize) since the actual resolution will reuse what it finds in the target platform. If it's empty, then it is
populated of course but when it's preset, everything in there will participate in the resolution.
B.t.w. what Buckminster version are you using?
HTH,
Thomas Hallgren
On 02/12/2010 02:17 PM, Matthias Kappeller wrote:
> Hi,
>
> I have defined an mspec to materialize some components into the target
> platform and some into the workspace.
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <mspec:mspec
> xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
> materializer="p2" installLocation="${targetPlatformPath}" name="myMSpec"
> url="a.cquery" conflictResolution="UPDATE">
> <mspec:mspecNode namePattern="^app1(\..+)?" componentType="osgi.bundle"
> materializer="workspace"/>
> </mspec:mspec>
>
>
> The 'targetPlatformPath' Property is defined in the cquery.
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <cq:componentQuery
> xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0"
> resourceMap="http://svn/trunk/rmap/a.rmap">
> <cq:rootRequest name="app1.component.a" componentType="buckminster"/>
> <cq:property key="targetPlatformPath"
> value="${workspace.root}/targetPlatform"/>
> </cq:componentQuery>
>
>
> After materialization in Eclipse the target platform can be set by using
> a target definition.
>
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <?pde version="3.5"?>
>
> <target name="WS4">
> <locations>
> <location path="${workspace_loc}/targetPlatform" type="Directory"/>
> </locations>
> </target>
>
>
> Because of all relative paths this works great inside Eclipse.
>
> As the next step i would take the mspec and build it with buckminster
> headless.
> I've configured hudson:
>
> resolve http://svn/trunk/mspec/a.mspec
> importtargetdefinition -A http://svn/trunk/target/a.target
> build
>
>
> And it doesn't work as expected :(
>
> The first "mystery" is, that the property defined in the cquery is not
> choosen. The components are materialized into
> BUCKMINSTER_HEADLESS_INSTALL_LOCATION/${targetPlatformPath}.
>
> After setting the property 'targetPlatformPath' in Hudson to
> '${WORKSPACE}/targetPlatform' the components have been materialized to
> the right directory.
>
> But it seems to be that the target definition couldn't find this
> directory, because the other components can not find the required bundles.
>
> What am I doing wrong? Am I not able to choose workspace relative paths
> within buckminster headless?
>
> Regards,
>
> Matthias
|
|
|
|
| Re: Sharing Target Definition [message #514150 is a reply to message #514134] |
Fri, 12 February 2010 15:45 |
|
On 02/12/2010 03:41 PM, Matthias Kappeller wrote:
> Hi Thomas,
>
> I'am using Buckminster 3.5 (buckminster.core is 1.1.350.r10920).
>
> Previously i have done the setup without the install location. This
> works fine inside Eclipse but Headless the error was 'Unable to
> determine target platform install location' (of course).
>
> So if I have understood you right, you suggest to remove the install
> location and configure hudson in the following way?
>
> importtargetdefinition -A http://svn/trunk/target/a.target
> resolve http://svn/trunk/mspec/a.mspec
> build
>
Yes. That's the right order.
- thomas
|
|
|
|
|
| Re: Sharing Target Definition [message #514158 is a reply to message #514155] |
Fri, 12 February 2010 16:14 |
|
On 02/12/2010 05:09 PM, Matthias Kappeller wrote:
> The log print out:
>
> INFO: importtargetdefinition '-A' 'http://svn/trunk/target/a.target'
> INFO: resolve 'http://svn/trunk/mspec/a.mspec'
> ERROR [0003] : Unable to determine target platform install location
> ERROR: Unable to determine target platform install location
> ERROR: Errors and Warnings
> org.eclipse.core.runtime.CoreException: Errors and Warnings
> at
> org.eclipse.buckminster.runtime.BuckminsterException.wrap(Bu ckminsterException.java:109)
>
> at
> org.eclipse.buckminster.core.materializer.MaterializationJob .internalRun(MaterializationJob.java:175)
>
> at
> org.eclipse.buckminster.core.materializer.MaterializationJob .run(MaterializationJob.java:144)
>
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Contains: [0003] : Unable to determine target platform install location
>
>
> Something's wrong. :(
Indeed. Can you try the same thing with our headless 3.6?
Regards,
Thomas Hallgren
|
|
|
| Re: Sharing Target Definition [message #514171 is a reply to message #514157] |
Fri, 12 February 2010 16:56 |
|
Aha. You can use ${workspace.root} though.
- thomas
On 02/12/2010 05:26 PM, Matthias Kappeller wrote:
> After replacing '${workspace_loc}' with an absolute path it works.
>
> It seems to be that this Eclipse property is not available in
> Buckminster Headless.
|
|
|
| Re: Sharing Target Definition [message #514172 is a reply to message #514171] |
Fri, 12 February 2010 16:58 |
|
Hmm, or perhaps you can't. This is inside a target platform definition. It's not parsed by Buckminster.
- thomas
On 02/12/2010 05:56 PM, Thomas Hallgren wrote:
> Aha. You can use ${workspace.root} though.
>
> - thomas
>
> On 02/12/2010 05:26 PM, Matthias Kappeller wrote:
>> After replacing '${workspace_loc}' with an absolute path it works.
>>
>> It seems to be that this Eclipse property is not available in
>> Buckminster Headless.
>
|
|
|
|
| Re: Sharing Target Definition [message #514225 is a reply to message #514177] |
Fri, 12 February 2010 21:36 |
|
On 02/12/2010 06:18 PM, Matthias Kappeller wrote:
> After some more random tests :) i've recognized that not the property
> ${workspace_loc} is the problem.
>
> Referencing a local target definition it works with or without the
> property.
> Referencing a remote target definition it will not work.
>
> Now I have to get the target definition from svn, and import it, before
> i resolve the components. hmm
>
Ideally, you'd let buckminster take care of the reslution instead of using a remote target platform.
Define your target platform as an empty directory. Use p2 readers to point to repositires. Let the providers have the
property source="false". The providers that fetch your source code intended for the workspace have source="true".
In your mspec, instead of using a name pattern, you just use a filter:
<?xml version="1.0" encoding="UTF-8"?>
<mspec:mspec xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0" materializer="p2" name="Buckminster MSPEC"
url="build-${eclipse.release}.cquery">
<mspec:mspecNode materializer="workspace" namePattern="" filter="(buckminster.source=true)"/>
</mspec:mspec>
This will make Buckminster populate both your workspace and your target platform. The target platform will not contain
anything that doesn't have to be there.
HTH,
- thomas
|
|
|
|
| Re: Sharing Target Definition [message #556935 is a reply to message #514225] |
Fri, 03 September 2010 08:55 |
Tomsen 
Messages: 42
Registered: July 2010 |
Member |
|
|
| Thomas Hallgren wrote on Fri, 12 February 2010 16:36 |
Ideally, you'd let buckminster take care of the reslution instead of using a remote target platform.
Define your target platform as an empty directory.
...
|
Thomas, how do I do this exactly? In the mspec itself by using
<mspec:mspec xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
installLocation="${workspace.root}/TP"
materializer="p2"
name="mspec"
url="build-${eclipse.release}.cquery">
Or is this only for headless builds and does not apply within the IDE?
I do not get the TP when I materialize from within the IDE.
Edit: Even with the mspec I get delta pack plugins materialized in the workspace ... arrrgh.
best regards
Thomas
[Updated on: Fri, 03 September 2010 10:26] Report message to a moderator |
|
|
| Re: Sharing Target Definition [message #556965 is a reply to message #556935] |
Fri, 03 September 2010 11:30 |
|
The simplest thing is probably to not use an mspec at all. Just trust the defaults that says that anything that is
materialized using a provider with source="true" ends up in the workspace and everything else ends up in the TP.
If you do want an mspec, then it's very rare to use the 'installLocation' attribute. The default is that buckminster
attempts to use directory container of the currently active target platform.
- thomas
On 09/03/2010 10:55 AM, Tomsen wrote:
> Thomas Hallgren wrote on Fri, 12 February 2010 16:36
>> Ideally, you'd let buckminster take care of the reslution instead of
>> using a remote target platform.
>>
>> Define your target platform as an empty directory. ...
>
> Thomas, how do I do this exactly? In the mspec itself by using
>
>
> <mspec:mspec
> xmlns:mspec="http://www.eclipse.org/buckminster/MetaData-1.0"
> installLocation="${workspace.root}/TP" materializer="p2" name="mspec"
> url="build-${eclipse.release}.cquery">
> ???
> Or is this only for headless builds and does not apply within the IDE?
>
> I do not get the TP when I materialize from within the IDE.
> best regards
>
> Thomas
|
|
|
|
|
| Re: Sharing Target Definition [message #557025 is a reply to message #556993] |
Fri, 03 September 2010 15:44 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Am 03.09.2010 16:23, schrieb Tomsen:
> Thomas, ok so far :)
> Now I want to try this in Hudson. I defined a free-style job to extract
> my releng module from svn first and start Buckminster to materialize and
> build ... how do I define an empty target platform that at least defines
> Galileo as the release? You suggested to just use an empty directory.
> But that is probably a question for Johannes ...
As usually there's different ways :)
One would be to do something like that as your first two buckminster
commands:
setpref targetPlatformPath=${WORKSPACE}TP
resolve your.releng.component/targetPlatform.cquery
The first command will activate an empty directory as your target
platform. Next you resolve a query to fill the workspace and the target
platform. Now there's essentially two options:
1. You resolve a query directly for your to-be-build-feature and have
the target platform resolved on the fly.
That makes sense for example if you don't care too much what bundles are
part of your target platform, you just want it to work. What bundles are
part of your TP is determined dynmically from your dependencies.
2. The other way is to first resolve a specific TP query (e.g. on a
component of type buckminster, or eclipse.feature). This query is only
responsible for bringing in the TP, not yet your build material.
Once that's done, you resolve a second query for your actual build
materials. This scenario makes sense when you explicitly want to define
and control what is part of your TP. So if you do this kind of build,
it's probably a good idea to use two different rmaps for the queries
that fetch your TP and your Build Material. You don't want to allow that
the dependencies of the Build Material alters your TP in any way (since
your first query explicitly defined what you consider your target
platform) so you give the rmap for this query no access to the internet
or any additional update sites.
No matter which one of these approaches you use, buckminster will decide
automatically if a resolved component ends up in your empty TP
directory, or in the workspace. Sources go to the workspace, binaries go
to the TP directory.
As a hint, if you want to avoid the overhead of materializing a complete
TP from scratch every time you build, you can introduce parameters to
your hudson build.
If you combine that with a simple shell script build-step like that:
if $clearTargetPlatform
then
echo "Deleting Target Platform"
rm -Rf TP
fi
you end up with a neat button in your build that allows you to decide if
you want to reuse the previously materialized TP, or delete it and fetch
a fresh one (for a release build for example).
Best regards,
Johannes
|
|
|
Powered by
FUDForum. Page generated in 0.03137 seconds
] 
Search
Help
Register
Login
Home
i've recognized that not the property ${workspace_loc} is the problem.