Eclipse Community Forums: Buckminster » The import org.eclipse.swt.ole cannot be resolved (again)

Home » Archived » Buckminster » The import org.eclipse.swt.ole cannot be resolved (again)(Building Windows app on Linux)

Show: Today's Messages :: Show Polls :: Message Navigator

The import org.eclipse.swt.ole cannot be resolved (again) [message #642235]

Tue, 30 November 2010 14:03

Stephan

Messages: 36
Registered: July 2009

Member

Hi

I recently changed the creation of our target platform. We now us several MSPEC as describe here:
http:// wiki.eclipse.org/Building_an_RCP_application_with_hudson_%28 Buckminster%29

Most of our applications build fine except one that uses Windows-specific SWT classes. Because the build runs on Linux, we tried to change the preferences as follows:
INFO: setpref 'targetPlatformPath=/var/lib/hudson/jobs/TargetPlatformWindo ws/builds/2010-11-30_11-14-45/archive//targetPlatform'
INFO: setpref 'org.eclipse.buckminster.pde.targetOS=win32'
INFO: setpref 'org.eclipse.buckminster.pde.targetWS=win32'
INFO: setpref 'org.eclipse.buckminster.pde.targetArch=x86'
INFO: lsprefs
Found 15 preference(s):
... (omitted)
org.eclipse.buckminster.pde.targetArch
Description: Sets the operating system architecture on the currently active target platform
Value : x86
org.eclipse.buckminster.pde.targetDefinition
Description: Sets the active Target Platform Definition
Value : Directory /var/lib/hudson/jobs/TargetPlatformWindows/builds/2010-11-30 _11-14-45/archive//targetPlatform
org.eclipse.buckminster.pde.targetNL
Description: Sets the locale of the currently active target platform
(no value set)
org.eclipse.buckminster.pde.targetOS
Description: Sets the operating system on the currently active target platform
Value : win32
org.eclipse.buckminster.pde.targetPlatformPath
Description: Set the active Target Platform to a definition that appoints a path
Value : /var/lib/hudson/jobs/TargetPlatformWindows/builds/2010-11-30 _11-14-45/archive/targetPlatform
org.eclipse.buckminster.pde.targetWS
Description: Sets the window system on the currently active target platform
Value : win32

Listing the target definitions results in:
INFO: listtargetdefinitions
Using workspace at file:/var/lib/hudson/jobs/CCTVnetWorkplace/workspace/ ...
* Directory /var/lib/hudson/jobs/TargetPlatformWindows/builds/2010-11-30 _11-14-45/archive//targetPlatform : win32,win32,x86/en_US
Running Platform : linux,gtk,x86/en_US

For my understanding, this looks correct but then I would expect that the build-command is succesful. What am I missing?

Thanks, Stephan

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642897 is a reply to message #642235]

Fri, 03 December 2010 09:16

Stephan

Messages: 36
Registered: July 2009

Member

Hi

In the meantime, I created a Windows-specific target definition that points to the exact same target platform:

<target name="tp-linux-win">
<locations>
<location path="/var/lib/hudson/jobs/TargetPlatform/lastStable/archive/targetPlatform" type="Profile"/>
</locations>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86</arch>
</environment>
</target>

and then use

importtargetdefinition -A '${WORKSPACE}trunk/com.diligentit.cctvnet.build/headlessLinux/tp/tp-linux-win.target'

instead of selecting the target platform in the Hudson Buckminster command and everything compiles again!

So there must be an important difference (bug?) between

setpref 'targetPlatformPath=/var/lib/hudson/jobs/TargetPlatform/lastStable/archive/targetPlatform'
setpref 'org.eclipse.buckminster.pde.targetOS=win32'
setpref 'org.eclipse.buckminster.pde.targetWS=win32'
setpref 'org.eclipse.buckminster.pde.targetArch=x86'

and

importtargetdefinition -A '${WORKSPACE}trunk/com.diligentit.cctvnet.build/headlessLinux/tp/tp-linux-win.target'

or I still have a misunderstanding. Any good explanation would make me more confident...

Cheers, Stephan

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642903 is a reply to message #642897]

Fri, 03 December 2010 09:30

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

On 2010-12-03 10:16, Stephan wrote:
> ... Any good explanation would make me more confident...
>
The target platform type is a "Profile" in your .target. The setpref targetPlatformPath=<dir> assumes a target platform
that is a directory.

HTH,

- thomas

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642907 is a reply to message #642903]

Fri, 03 December 2010 10:08

Stephan

Messages: 36
Registered: July 2009

Member

Hi Thomas

> The target platform type is a "Profile" in your .target. The setpref
> targetPlatformPath=<dir> assumes a target platform
> that is a directory.

My target platform is stored in a directory that contains a layout as exported by the Buckminster Hudson plugin when "Archive and publish an Eclipse Target Platform" is selected. What is the expected difference between "Profile" and "Directory" location types?

Thanks, Stephan

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642920 is a reply to message #642907]

Fri, 03 December 2010 10:39

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

On 2010-12-03 11:08, Stephan wrote:
> Hi Thomas
>
> My target platform is stored in a directory that contains a layout as exported by the Buckminster Hudson plugin when
> "Archive and publish an Eclipse Target Platform" is selected. What is the expected difference between "Profile" and
> "Directory" location types?
>
A "Directory" contains a p2 artifact repository with plug-ins in installed form (i.e. jars normally unpacked during
install will be in folder form, not jars).

To be honest, I've never used the "Archive and publish an Eclipse Target Platform" myself, so I don't know what the
resulting layout looks like. Perhaps Johannes Utzig (author of the Hudson plug-in) can answer that.

Regards,
Thomas Hallgren

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642936 is a reply to message #642920]

Fri, 03 December 2010 12:33

Stephan

Messages: 36
Registered: July 2009

Member

Hi Thomas

The archived target platform from the Buckminster Hudson plugin has the following contents:

artifacts.xml
features
- features/org.eclipse.equinox.executable_3.4.1.R36x_v20100823-7M7K7JF90dnJ-WLf3cf4yi
- features/org.eclipse.equinox.executable_3.4.1.R36x_v20100823-7M7K7JF90dnJ-WLf3cf4yi/license.html
...
plugins
- plugins/org.eclipse.equinox.p2.artifact.repository_1.1.1.R36x_v20100901.jar
- plugins/org.eclipse.ui.intro.universal_3.2.402.r36_v20100702
-- plugins/org.eclipse.ui.intro.universal_3.2.402.r36_v20100702/plugin.xml
...

All features and some plugins are extracted so I assume this is the correct form for setpref targetPlatformPath, isnt't it?

Cheers, Stehan

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642939 is a reply to message #642936]

Fri, 03 December 2010 12:40

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

Hi Stephan,

On 2010-12-03 13:33, Stephan wrote:
> Hi Thomas
>
> The archived target platform from the Buckminster Hudson plugin has the following contents:
>
> artifacts.xml
> features
> - features/org.eclipse.equinox.executable_3.4.1.R36x_v20100823 -7M7K7JF90dnJ-WLf3cf4yi
> - features/org.eclipse.equinox.executable_3.4.1.R36x_v20100823 -7M7K7JF90dnJ-WLf3cf4yi/license.html
> ...
> plugins
> - plugins/org.eclipse.equinox.p2.artifact.repository_1.1.1.R36 x_v20100901.jar
> - plugins/org.eclipse.ui.intro.universal_3.2.402.r36_v20100702
> -- plugins/org.eclipse.ui.intro.universal_3.2.402.r36_v20100702 /plugin.xml
> ...
>
> All features and some plugins are extracted so I assume this is the correct form for setpref targetPlatformPath, isnt't it?
>
Yes, it looks correct. What buckminster does when you use the targetPlatformPath preference is that it creates a target
platform definition similar to the one you have but with the type "Directory". That's the only difference I can see.
Buckminster then uses the same mechanism for importing this platform as it does when you use the importtargetplatform
command.

What kind of errors do you see?

- thomas

Report message to a moderator

Re: The import org.eclipse.swt.ole cannot be resolved (again) [message #642958 is a reply to message #642939]

Fri, 03 December 2010 14:06

Stephan

Messages: 36
Registered: July 2009

Member

Hi Thomas

> What kind of errors do you see?

I get a compile error during the build-command because I my RCP application uses Windows-specific classes like org.eclipse.swt.ole.win32.OleAutomation (see title).

I also wondered if the ordering of the preferences is correct. According to the preference descriptions they affect the currently active target platform but the following would make more sense to me:

setpref 'org.eclipse.buckminster.pde.targetOS=win32'
setpref 'org.eclipse.buckminster.pde.targetWS=win32'
setpref 'org.eclipse.buckminster.pde.targetArch=x86'
setpref 'targetPlatformPath=/var/lib/hudson/jobs/TargetPlatform/lastStable/archive/targetPlatform'

Could this be another difference?

Regards, Stephan

Report message to a moderator

Previous Topic:	SVN provider assumptions...?
Next Topic:	p2 site HTML contents

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 07:11:13 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter