Re: Buckminster build in hudson with precreated target platform [message #721465] |
Thu, 01 September 2011 16:16  |
Eclipse User |
|
|
|
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.
Why are you doing two different resolves b.t.w.? What's the purpose of the second one?
- thomas
|
|
|
|
Re: Buckminster build in hudson with precreated target platform [message #721545 is a reply to message #721472] |
Fri, 02 September 2011 01:08   |
Eclipse User |
|
|
|
On 2011-09-01 22:53, Lothar Werzinger wrote:
> Thomas Hallgren wrote on Thu, 01 September 2011 13:16
>> 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.
>
>
> That's what I am doing.
> Using the precreated TP (from the test_tp job) I try to build a site (in the test_build job)
>
> This are the commands I am using:
>
> resolve ../mmt-tools.cquery
> perform biz.tradescape.mmt.cdoserver.feature#site.p2
>
AFAICS, your errors occur during resolve. So I repeat, the cbi.include.source has no relevance when you do a resolve.
>> Why are you doing two different resolves b.t.w.? What's the purpose of the second one?
>>
>
> Not sure what two different resolves you are talking about.
> What I am trying to do is to create a target platform that will be used for
>
>
> development in the IDE 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.
- thomas
> 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.
|
|
|
|
|
|
|
|
Re: Buckminster build in hudson with precreated target platform [message #721746 is a reply to message #721583] |
Fri, 02 September 2011 13:52   |
Eclipse User |
|
|
|
Thomas Hallgren wrote on Fri, 02 September 2011 00:55
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 the jobs have independent workspaces the build job won't be able to access anything unless the cquery materializes it out of the TP, right?
Thomas Hallgren wrote on Fri, 02 September 2011 00:55
> 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.
Thanks!
Thomas Hallgren wrote on Fri, 02 September 2011 00:55
>
> 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
No problem, just seemed strange at first sight.
|
|
|
Re: Buckminster build in hudson with precreated target platform [message #721754 is a reply to message #721585] |
Fri, 02 September 2011 14:16   |
Eclipse User |
|
|
|
Thomas Hallgren wrote on Fri, 02 September 2011 01:00
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.
One big reason trying to use buckminster to build the TP is that I had severe problems creating stable TPs with the "Target definition editor". Especially for complicated targets that are composed from different update sites. Compared to that defining and materializing the TP with buckminster was easy. I especially hate that the target definition editor sometimes "forgets" what features and plugins you selected when you open the target definition for editing.
Using the buckminster created TP in the IDE is easy, too as I can create a simple target definition file that points to the directory containing the TP. I already did that and the IDE works fine with the generated TP, as it does not need the source plugins.
Using buckminster for build looks very attractive, too in comparison to the ugly PDE build based build that we use now. Especially as we would like to have p2 update sites in conjunction with zip based products in the future and not only zip product builds.
Thomas Hallgren wrote on Fri, 02 September 2011 01:00
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
If I want to guarantee that the individual resolves resolve exactly the same plugins it seems that a local mirror is required. I don't want anyone starting with a new workspace to get different plugins to build against by chance. The precreated TP seems to solve the problem nicely.
Being new to buckminster I also don't understand yet how buckminster handles the TP during development. I know you can call buckminster to do the actual build of your product out of the IDE with the buckminster menu, but what about development and debugging with the regular incremental builds in the IDE?
|
|
|
|
|
|
|
|
|
|
Re: Buckminster build in hudson with precreated target platform [message #722483 is a reply to message #722425] |
Mon, 05 September 2011 18:28  |
Eclipse User |
|
|
|
If step 2) does not specify any platform filter, it will be filtered for
the current platform. Here, you probably want to use '*' so you get a TP
for all platforms. e.g. os, ws and arch should all be * (or some sane
set that gets you everything that you want, i.e. os and ws are * and
arch = x86)
Then in 4 and 5 you (correctly) specify that you want a build for
windows but was probably already filtered in 2) so it fails.
- henrik
On 9/5/11 8:31 PM, Stephan wrote:
> Sorry, when I was too less specific: We develop on Windows and run
> headless builds on Linux/Hudson:
> - Running an action within the IDE (Buckminster > Invoke action) on
> Windows is not a problem because the TP is already Windows-specific
> (when using the running platform). - Building on Linux works a bit
> different and consists of the following headless commands:
> 1) importtargetdefinition -A
> '${WORKSPACE}trunk/com.diligentit.cctvnet.build/headlessLinux/tp/tp-linux-win.target'
>
> 2) import
> '${WORKSPACE}trunk/com.diligentit.cctvnet.workplace.build/site.cquery'
> 3) build
> 4) perform -P
> '${WORKSPACE}trunk/com.diligentit.cctvnet.build/headlessLinux/buildsite-win32.properties'
> com.diligentit.cctvnet.workplace.build#site.p2
> 5) perform -D target.os=win32 -D target.ws=win32 -D target.arch=x86
> com.diligentit.cctvnet.workplace.build#create.product.zip
>
> This all works pretty well. Now the whole exercise is to get rid of 1)
> and resolve source and TP in 2), correct? The problem is that "step 3) -
> build" fails because it cannot find the Windows-specific OLE classes.
> Should "step 2) - import" already set os/ws to win32/win32? Would this
> create a Windows-specific TP?
>
> Thanks, Stephan
>
|
|
|
Powered by
FUDForum. Page generated in 0.09176 seconds