On 2011-09-01 22:05, Lothar Werzinger wrote:
> I tried to set the property cbi.include.source to false as described in the buckminster book, but the build still looks
> for the unavailable org.apache.commons.logging.source bundle.
>
The cbi.include.source has no relevance when you do a resolve. It's only valid when you build a site.

resolve ../mmt-tools.cquery
perform biz.tradescape.mmt.cdoserver.feature#site.p2

Why are you doing two different resolves b.t.w.? What's the purpose of the second one?

- thomas

1. development in the IDE
   
2. automatic builds in hudson
   

I see the test_rcp.cquery/test_rcp.rmap. From the looks of it, they resolve/materialize both your target platform and
your workspace. Then there's a mmt-tools.cquery/mmt-tools.rmap. Not sure what they do but they seem redundant.

> P.S.
> just curious; why did you create a new thread instead of replying to the existing one?

Not sure what you mean, this is my sixth reply in this thread. All postings, from your original posting, shows up as as
single thread in my news reader.

Hi Lothar

We do something very similar:

Then we have a different job that executes the following commands to build the site:
importtargetdefinition -A '${WORKSPACE}/......../tp-37.target'
import '${WORKSPACE}/......../source.cquery'
build
perform some.feature#site.p2

I missed importtargetdefinition in your command list above. Did you try that?

Cheers, Stephan

setpref targetPlatformPath="/var/lib/hudson/jobs/test_tp/builds/2011-09-01_12-38-00/archive//targetPlatform"

On 2011-09-02 07:40, Lothar Werzinger wrote:
> Thomas Hallgren wrote on Thu, 01 September 2011 22:08
>> I see the test_rcp.cquery/test_rcp.rmap. From the looks of it, they resolve/materialize both your target platform and
>> your workspace. Then there's a mmt-tools.cquery/mmt-tools.rmap. Not sure what they do but they seem redundant.
>
>
> test_rcp.cquery/test_rcp.rmap are from the job that builds the TP
> mmt-tools.cquery/mmt-tools.rmap is from the job that tries to buils site.p2 using the previouly materialized TP.
>
There must be some misunderstanding then. You don't need to re-resolve before when you perform unless you switch
workspace between the attempts.

> As outlined in another post the goal is to have a TP (immutable after creation) that is used for development in the IDE
> as well as for all automatic builds.

The TP is never changed during a build.

> As I had trouble with the build part I reduced it to simply building a feature composed of other features in the TP, so
> that I didn't have to distribute code to compile in the sample I provided to reproduce the issue.
>
OK, that's fine. The problem I will look at is why you don't get both source bundles into your TP. I have what I need to
do that.

>
> I am using the web forum and for whatever reasons it shows up as another thread there.

The web-forum apparently has some flaws...

- thomas

On 2011-09-02 09:11, Stephan wrote:
> I missed importtargetdefinition in your command list above. Did you try that?
>
The importtargetdefinition uses the PDE target definition construct. Lothar uses Buckminster to build the target
platform based in the cquery/rmap dependency resolution.

All our builds use Buckminster to resolve both the target platform and the workspace at the same time. I've found that
approach much more flexible and less error prone. Rebuilding the TP is never a problem unless the p2 repositories that
serve up the TP are very slow. And if they are, you can always create a local mirror of them instead of a pre-defined
target platform.

IMO, using p2 repositories rather than pre-defined TP's as input to your build is more flexible.

- thomas