Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » Problem with Target Platform Definition (using ${git_work_tree} variable)
Problem with Target Platform Definition [message #1002374] Fri, 18 January 2013 08:30 Go to previous message
Christoph Keimel is currently offline Christoph Keimel
Messages: 277
Registered: December 2010
Location: Germany
Senior Member
Hello Bucky Team

I am currently trying to setup an rcp build using buckminster. During the process I came over the following issue with the target definition.

We use a target definition which only uses plugins (jar files) which are placed in a general eclipse project. This project is placed in a git repository. Therefor the target definition itself looks like this, so it is identical for every developer regardless of the location of his git repository.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?>
<target name="GO§A Target" sequenceNumber="280">
	<locations>
		<location path="${git_work_tree}/lib/Target/test" type="Directory"/>
		<location path="${git_work_tree}/lib/Target/eclipse" type="Directory"/>
		<location path="${git_work_tree}/lib/Target/extensions" type="Directory"/>
	</locations>
	... skipped ...
</target>


This works in PDE but does not get resolved correctly by buckminster. If I use full path names instead of the ${git_work_tree} property everything works fine.

Is there a way I can let buckminster know where to look for ${git_work_tree}?

Version: Juno Service Release 1
Build id: 20121004-1855
Buckminster Core 1.5.0.v20121128-1508

Greetings
Christoph

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic:materializing using an MSPEC
Next Topic:Component is not known to Buckminster
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu May 23 08:51:31 EDT 2013

Powered by FUDForum. Page generated in 0.01809 seconds