Eclipse Community Forums: Buckminster » The import org.eclipse.swt cannot be resolved

Home » Archived » Buckminster » The import org.eclipse.swt cannot be resolved

The import org.eclipse.swt cannot be resolved [message #988987]

Tue, 04 December 2012 02:43

Eclipse User

Hi,

Since November 28 our Hudson (linux) build keeps failing because SWT can not be resolved:
https://hudson.eclipse.org/hudson/job/emf-cdo-integration

The target platform only contains a org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar
<https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins/org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar>
fragment: https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins

That might explain why the build works at home on Windows. But where have the other platform fragments gone? Any ideas?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989019 is a reply to message #988987]

Tue, 04 December 2012 05:38

Eclipse User

On 12/04/2012 08:43 AM, Eike Stepper wrote:
> Hi,
>
> Since November 28 our Hudson (linux) build keeps failing because SWT can
> not be resolved: https://hudson.eclipse.org/hudson/job/emf-cdo-integration
>
> The target platform only contains a
> org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar
> <https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins/org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar>
> fragment:
> https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins
>
>
> That might explain why the build works at home on Windows. But where
> have the other platform fragments gone? Any ideas?
>

Hi

for curiosity (I'm recently taking a look at projects which use
buckminster to get inspiration ;) I took a look here

http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.releng/build.cquery

I don't know if that is the cause, but you skip some gtk components from
swt and equinox ...

sorry if I said something stupid :)

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net

Re: The import org.eclipse.swt cannot be resolved [message #989114 is a reply to message #989019]

Tue, 04 December 2012 11:40

Eclipse User

Am 04.12.2012 11:38, schrieb Lorenzo Bettini:
> On 12/04/2012 08:43 AM, Eike Stepper wrote:
>> Hi,
>>
>> Since November 28 our Hudson (linux) build keeps failing because SWT can
>> not be resolved: https://hudson.eclipse.org/hudson/job/emf-cdo-integration
>>
>> The target platform only contains a
>> org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar
>> <https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins/org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar>
>> fragment:
>> https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins
>>
>>
>> That might explain why the build works at home on Windows. But where
>> have the other platform fragments gone? Any ideas?
>>
> Hi
>
> for curiosity (I'm recently taking a look at projects which use
> buckminster to get inspiration ;) I took a look here
>
> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.releng/build.cquery
>
> I don't know if that is the cause, but you skip some gtk components from
> swt and equinox ...
Hmm, it doesn't look like the cause to me. I'm only excluding source components and fragments for unneeded platforms.
And I've not touched that file for ages. Nevertheless I'm trying a build with those lines commented out...

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989248 is a reply to message #989114]

Wed, 05 December 2012 05:53

Eclipse User

On 12/04/2012 05:40 PM, Eike Stepper wrote:
> Am 04.12.2012 11:38, schrieb Lorenzo Bettini:
>> On 12/04/2012 08:43 AM, Eike Stepper wrote:
>>> Hi,
>>>
>>> Since November 28 our Hudson (linux) build keeps failing because SWT can
>>> not be resolved:
>>> https://hudson.eclipse.org/hudson/job/emf-cdo-integration
>>>
>>> The target platform only contains a
>>> org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar
>>> <https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins/org.eclipse.swt.win32.win32.x86_64_3.8.1.v3834e.jar>
>>>
>>> fragment:
>>> https://hudson.eclipse.org/hudson/job/emf-cdo-integration/ws/result/tp/plugins
>>>
>>>
>>>
>>> That might explain why the build works at home on Windows. But where
>>> have the other platform fragments gone? Any ideas?
>>>
>> Hi
>>
>> for curiosity (I'm recently taking a look at projects which use
>> buckminster to get inspiration ;) I took a look here
>>
>> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.releng/build.cquery
>>
>>
>> I don't know if that is the cause, but you skip some gtk components from
>> swt and equinox ...
> Hmm, it doesn't look like the cause to me. I'm only excluding source
> components and fragments for unneeded platforms. And I've not touched
> that file for ages. Nevertheless I'm trying a build with those lines
> commented out...
>

The error seems different now... it looks like it can't find
javax.annotations...

https://hudson.eclipse.org/hudson/job/emf-cdo-integration/2554/console

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net

Re: The import org.eclipse.swt cannot be resolved [message #989312 is a reply to message #989248]

Wed, 05 December 2012 10:51

Eclipse User

Am 05.12.2012 11:53, schrieb Lorenzo Bettini:
> The error seems different now... it looks like it can't find javax.annotations...
> https://hudson.eclipse.org/hudson/job/emf-cdo-integration/2554/console
Yeah, that was an attempt to use fixed os/ws/arch parameters. It obviously failed. And it couldn't be an end solution
because our build used to produce example products for multiple platforms ;-(

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989359 is a reply to message #989312]

Wed, 05 December 2012 15:12

Eclipse User

On 12/05/2012 04:51 PM, Eike Stepper wrote:
> Am 05.12.2012 11:53, schrieb Lorenzo Bettini:
>> The error seems different now... it looks like it can't find
>> javax.annotations...
>> https://hudson.eclipse.org/hudson/job/emf-cdo-integration/2554/console
> Yeah, that was an attempt to use fixed os/ws/arch parameters. It
> obviously failed. And it couldn't be an end solution because our build
> used to produce example products for multiple platforms ;-(
>

But you don't use

<cq:property key="target.arch" value="*"/>
<cq:property key="target.os" value="*"/>
<cq:property key="target.ws" value="*"/>

in your cquery, do you?

probably it's in a properties file, I guess...

I don't know whether your problem is related to this, but on 28
November, Thomas released a fix for this bug

https://bugs.eclipse.org/bugs/show_bug.cgi?id=395070

and it looks like your job stopped working on that date...

but I don't know the internal details, Thomas will have to say something :)

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net

Re: The import org.eclipse.swt cannot be resolved [message #989404 is a reply to message #989359]

Thu, 06 December 2012 01:07

Eclipse User

Am 05.12.2012 21:12, schrieb Lorenzo Bettini:
> But you don't use
>
> <cq:property key="target.arch" value="*"/>
> <cq:property key="target.os" value="*"/>
> <cq:property key="target.ws" value="*"/>
>
> in your cquery, do you?
Hmm, strange. I have those in my build.mspec:

<mspec:property key="target.os" value="*"/>
<mspec:property key="target.ws" value="*"/>
<mspec:property key="target.arch" value="*"/>

> probably it's in a properties file, I guess...
Plus I have them in my build.properties:

target.os=*
target.ws=*
target.arch=*

Thomas, can you please explain where these settings are all needed or where I can read about that?

> I don't know whether your problem is related to this, but on 28
> November, Thomas released a fix for this bug
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=395070
>
> and it looks like your job stopped working on that date...
I already tried to use the previous build from http://archive.eclipse.org/tools/buckminster/archivedsites-4.2 - To no
effect. Maybe I've done soemthing wrong and instead still used the newest build. I thought I compared the versions
during the tool installation.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989414 is a reply to message #989359]

Thu, 06 December 2012 02:14

Eclipse User

Am 05.12.2012 21:12, schrieb Lorenzo Bettini:
>
> But you don't use
>
> <cq:property key="target.arch" value="*"/>
> <cq:property key="target.os" value="*"/>
> <cq:property key="target.ws" value="*"/>
>
> in your cquery, do you?
Lorenzo, you saved my entire week ;-)

I added the <cq:property> lines and in fact the build succeeds again!!!

You're the greatest. I'd never have expected that I must specify this in a third place. Thank you again.

It strikes me that the redundant (3 times) definition is not ideal. I'd still like to learn about what impact these
properties have depending on where they're specified...

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989424 is a reply to message #989414]

Thu, 06 December 2012 03:00

Eclipse User

On 2012-12-06 08:14, Eike Stepper wrote:
> Am 05.12.2012 21:12, schrieb Lorenzo Bettini:
>>
>> But you don't use
>>
>> <cq:property key="target.arch" value="*"/>
>> <cq:property key="target.os" value="*"/>
>> <cq:property key="target.ws" value="*"/>
>>
>> in your cquery, do you?
> Lorenzo, you saved my entire week ;-)
>
> I added the <cq:property> lines and in fact the build succeeds again!!!
>
> You're the greatest. I'd never have expected that I must specify this in
> a third place. Thank you again.
>
You shouldn't need to provided that they are passed in as properties on
the command line.

> It strikes me that the redundant (3 times) definition is not ideal. I'd
> still like to learn about what impact these properties have depending on
> where they're specified...
>
One time should be enough. The properties passed on the command line are
merged with the ones from the cquery and the rmap. The mspec ones should
be passed to unless you first resolve using the cquery and then, as a
separate step perform the materialization using your mspec and a bom file.

So questions:
1. How is Buckminster made aware of your build.properties settings?
2. What command or commands are used for resolving and materializing?
3. Did any of this change recently? What happened on November 28?

- thomas

Re: The import org.eclipse.swt cannot be resolved [message #989435 is a reply to message #989424]

Thu, 06 December 2012 03:42

Eclipse User

Am 06.12.2012 09:00, schrieb Thomas Hallgren:
> On 2012-12-06 08:14, Eike Stepper wrote:
>> Am 05.12.2012 21:12, schrieb Lorenzo Bettini:
>>>
>>> But you don't use
>>>
>>> <cq:property key="target.arch" value="*"/>
>>> <cq:property key="target.os" value="*"/>
>>> <cq:property key="target.ws" value="*"/>
>>>
>>> in your cquery, do you?
>> Lorenzo, you saved my entire week ;-)
>>
>> I added the <cq:property> lines and in fact the build succeeds again!!!
>>
>> You're the greatest. I'd never have expected that I must specify this in
>> a third place. Thank you again.
>>
> You shouldn't need to provided that they are passed in as properties on the command line.
>
>> It strikes me that the redundant (3 times) definition is not ideal. I'd
>> still like to learn about what impact these properties have depending on
>> where they're specified...
>>
> One time should be enough. The properties passed on the command line are merged with the ones from the cquery and the
> rmap. The mspec ones should be passed to unless you first resolve using the cquery and then, as a separate step
> perform the materialization using your mspec and a bom file.
>
> So questions:
> 1. How is Buckminster made aware of your build.properties settings?
All this has initially been set up by you and Mikael. I think it is like this:

1. the build.xml imports build.properties.
2. then it echoes all properties to a variable (properties.tmp)
3. in the bucky call they're passed like this:

<arg value="@{command}" />
<arg value="-P" />
<arg value="${properties.tmp}" />
<cmdargs />

> 2. What command or commands are used for resolving and materializing?
<buckminster command="import">
<cmdargs>
<arg value="-B" />
<arg value="${hudson.WORKSPACE}/bom.xml" />

<arg value="-P" />
<arg value="${basedir}/build.properties" />


<arg value="${basedir}/build.mspec" />
</cmdargs>
</buckminster>

> 3. Did any of this change recently? What happened on November 28?
No, the last commit to our maintenance branch was almost exactly 1 month *before* the failures started (Nov. 28).

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989442 is a reply to message #989435]

Thu, 06 December 2012 04:14

Eclipse User

On 2012-12-06 09:42, Eike Stepper wrote:
> Am 06.12.2012 09:00, schrieb Thomas Hallgren:
>> 3. Did any of this change recently? What happened on November 28?
> No, the last commit to our maintenance branch was almost exactly 1 month
> *before* the failures started (Nov. 28).
>
This issue really displays all the traits of a regression in the build
system. You tested with:

org.eclipse.buckminster.site.eclipse.headless_1.5.0.v20121118-2330.zip

and that displayed the same problems. Are you sure that this is the one
that your build was using previously? I guess the answer is yes, you
always pick the latest from our headless site. But just to be sure,
could you try with the version before that, i.e.

http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/archivedsites-4.2/org.eclipse.buckminster.site.eclipse.headless_1.5.0.v20121007-1625.zip

or if there's a chance to set up a sandbox where I could try and save
you the time of doing it, that would be fine too. It just seems so odd
that your build suddenly require parameters that it didn't use to have
even though nothing changed.

- thomas

Re: The import org.eclipse.swt cannot be resolved [message #989466 is a reply to message #989442]

Thu, 06 December 2012 05:36

Eclipse User

Am 06.12.2012 10:14, schrieb Thomas Hallgren:
> On 2012-12-06 09:42, Eike Stepper wrote:
>> Am 06.12.2012 09:00, schrieb Thomas Hallgren:
>>> 3. Did any of this change recently? What happened on November 28?
>> No, the last commit to our maintenance branch was almost exactly 1 month
>> *before* the failures started (Nov. 28).
>>
> This issue really displays all the traits of a regression in the build system. You tested with:
>
> org.eclipse.buckminster.site.eclipse.headless_1.5.0.v20121118-2330.zip
>
> and that displayed the same problems. Are you sure that this is the one that your build was using previously? I guess
> the answer is yes, you always pick the latest from our headless site. But just to be sure, could you try with the
> version before that, i.e.
>
> http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/archivedsites-4.2/org.eclipse.buckminster.site.eclipse.headless_1.5.0.v20121007-1625.zip
>
Wow, with that version it works, too: https://hudson.eclipse.org/hudson/job/emf-cdo-integration/2565/console

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
> or if there's a chance to set up a sandbox where I could try and save you the time of doing it, that would be fine
> too. It just seems so odd that your build suddenly require parameters that it didn't use to have even though nothing
> changed.
>
> - thomas
>

Re: The import org.eclipse.swt cannot be resolved [message #989472 is a reply to message #989466]

Thu, 06 December 2012 06:07

Eclipse User

On 2012-12-06 11:36, Eike Stepper wrote:
> Am 06.12.2012 10:14, schrieb Thomas Hallgren:
>> On 2012-12-06 09:42, Eike Stepper wrote:
>>> Am 06.12.2012 09:00, schrieb Thomas Hallgren:
>>>> 3. Did any of this change recently? What happened on November 28?
>>> No, the last commit to our maintenance branch was almost exactly 1 month
>>> *before* the failures started (Nov. 28).
>>>
>> This issue really displays all the traits of a regression in the build
>> system. You tested with:
>>
>> org.eclipse.buckminster.site.eclipse.headless_1.5.0.v20121118-2330.zip
>>
>> and that displayed the same problems. Are you sure that this is the
>> one that your build was using previously? I guess the answer is yes,
>> you always pick the latest from our headless site. But just to be
>> sure, could you try with the version before that, i.e.
>>
>> http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/archivedsites-4.2/org.eclipse.buckminster.site.eclipse.headless_1.5.0.v20121007-1625.zip
>>
> Wow, with that version it works, too:
> https://hudson.eclipse.org/hudson/job/emf-cdo-integration/2565/console
>
OK. So that suggests a regression between our 20121007 and 20121118
versions that somehow affects how properties are passed from the mspec
during import. I'll investigate that.

Thanks a lot for investing time helping with this Eike. It would be hard
to track things down if you didn't.

- thomas

Re: The import org.eclipse.swt cannot be resolved [message #989482 is a reply to message #989472]

Thu, 06 December 2012 07:28

Eclipse User

Am 06.12.2012 12:07, schrieb Thomas Hallgren:
> OK. So that suggests a regression between our 20121007 and 20121118 versions that somehow affects how properties are
> passed from the mspec during import. I'll investigate that.
>
> Thanks a lot for investing time helping with this Eike. It would be hard to track things down if you didn't.
>
> - thomas
>

Re: The import org.eclipse.swt cannot be resolved [message #989483 is a reply to message #989482]

Thu, 06 December 2012 07:29

Eclipse User

Am 06.12.2012 13:28, schrieb Eike Stepper:
> Am 06.12.2012 12:07, schrieb Thomas Hallgren:
>> OK. So that suggests a regression between our 20121007 and 20121118 versions that somehow affects how properties are
>> passed from the mspec during import. I'll investigate that.
>>
>> Thanks a lot for investing time helping with this Eike. It would be hard to track things down if you didn't.
>>
>> - thomas
>>
>
Hmm, what did I want to say?! You're welcome :P

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: The import org.eclipse.swt cannot be resolved [message #989735 is a reply to message #989424]

Fri, 07 December 2012 08:12

Eclipse User

On 12/06/2012 09:00 AM, Thomas Hallgren wrote:
> One time should be enough. The properties passed on the command line are
> merged with the ones from the cquery and the rmap. The mspec ones should
> be passed to unless you first resolve using the cquery and then, as a
> separate step perform the materialization using your mspec and a bom file.

Hi Thomas

concerning the merging of properties I noted a behavior which I do not
know whether it's the one expected: I've set up for one of my projects a
cquery to materialize all the projects in the workspace

http://emf-components.eclipselabs.org.codespot.com/git/releng/it.rcpvision.emf.components.buckminster/remote/web-build.cquery

the URL is thought to be opened in the IDE and it clones the git repo,
materialize target platform and all projects in the workspace.

In the rmap I have some properties, like git.clone.dest, that I can
redefine, for instance, in a Jenkins job when calling buckminster
headlessly. The default value for such properties is in the rmap.
Everything works.

Now, if I try to put a default value for these properties in the cquery,
then the values passed on the command line are ignored...

is it the expected behavior (it's not a problem for my context)?
Otherwise it might be somehow related to Eike's problem?

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net

Previous Topic:	Buckminster calling product.ant (from example)
Next Topic:	equinox repository prefs are not installed

Goto Forum:

-=] Back to Top [=-

Current Time: Mon Apr 21 08:44:18 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter