Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » Using workspace relative target definition
Using workspace relative target definition [message #514111] Fri, 12 February 2010 13:17 Go to next message
Matthias Kappeller is currently offline 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 Sad

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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 #514134 is a reply to message #514126] Fri, 12 February 2010 14:41 Go to previous messageGo to next message
Matthias Kappeller is currently offline Matthias Kappeller
Messages: 54
Registered: July 2009
Member
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


Thomas Hallgren wrote on Fri, 12 February 2010 04: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


Re: Sharing Target Definition [message #514150 is a reply to message #514134] Fri, 12 February 2010 15:45 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 #514155 is a reply to message #514150] Fri, 12 February 2010 16:09 Go to previous messageGo to next message
Matthias Kappeller is currently offline Matthias Kappeller
Messages: 54
Registered: July 2009
Member
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(BuckminsterException.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. Sad
Re: Sharing Target Definition [message #514157 is a reply to message #514155] Fri, 12 February 2010 16:26 Go to previous messageGo to next message
Matthias Kappeller is currently offline Matthias Kappeller
Messages: 54
Registered: July 2009
Member
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 #514158 is a reply to message #514155] Fri, 12 February 2010 16:14 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 #514177 is a reply to message #514172] Fri, 12 February 2010 17:18 Go to previous messageGo to next message
Matthias Kappeller is currently offline Matthias Kappeller
Messages: 54
Registered: July 2009
Member
After some more random tests Smile 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

regards, matthias

> Hmm, or perhaps you can't. This is inside a target platform definition. It's not parsed by Buckminster.
>
>- thomas
Re: Sharing Target Definition [message #514225 is a reply to message #514177] Fri, 12 February 2010 21:36 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 #514237 is a reply to message #514225] Fri, 12 February 2010 23:11 Go to previous messageGo to next message
Matthias Kappeller is currently offline Matthias Kappeller
Messages: 54
Registered: July 2009
Member
I will give it a try.

Thank you a lot!

regards, matthias
Re: Sharing Target Definition [message #556935 is a reply to message #514225] Fri, 03 September 2010 08:55 Go to previous messageGo to next message
Tomsen  is currently offline 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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
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 #556993 is a reply to message #556965] Fri, 03 September 2010 14:23 Go to previous messageGo to next message
Tomsen  is currently offline Tomsen
Messages: 42
Registered: July 2010
Member
Thomas, ok so far Smile
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 ...
Re: Sharing Target Definition [message #557023 is a reply to message #556993] Fri, 03 September 2010 15:39 Go to previous messageGo to next message
Peter Kullmann is currently offline Peter Kullmann
Messages: 199
Registered: July 2009
Senior Member
I do it like this: I have a target feature that includes
org.eclipse.platform.feature.group, version 3.5.2.xyz... for example. In
my site feature I have a cquery for this target feature (which I don't
want to include in my site) and I materialize this first and the the
site.cquery.

Peter

Tomsen schrieb:
> 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 ...
Re: Sharing Target Definition [message #557025 is a reply to message #556993] Fri, 03 September 2010 15:44 Go to previous message
Johannes Utzig is currently offline 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
Previous Topic:Git Branches/Tags
Next Topic:product feature cannot be resolved in build
Goto Forum:
  


Current Time: Tue Sep 30 15:51:08 GMT 2014

Powered by FUDForum. Page generated in 0.02765 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software