|
| Re: Sharing Target Definition [message #514126 is a reply to message #514111] |
Fri, 12 February 2010 04:12   |
Eclipse User |
|
|
|
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 #557025 is a reply to message #556993] |
Fri, 03 September 2010 11:44 |
| Eclipse User |
|
|
|
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.06001 seconds
Home
i've recognized that not the property ${workspace_loc} is the problem.