Home » Archived » Buckminster » The import org.eclipse.swt cannot be resolved
| | |
| Re: The import org.eclipse.swt cannot be resolved [message #989248 is a reply to message #989114] |
Wed, 05 December 2012 10:53   |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
| Re: The import org.eclipse.swt cannot be resolved [message #989359 is a reply to message #989312] |
Wed, 05 December 2012 20:12 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| | |
| Re: The import org.eclipse.swt cannot be resolved [message #989424 is a reply to message #989414] |
Thu, 06 December 2012 08:00 |
|
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 08:42 |
|
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" />
<!-- Last argument: -->
<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
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 09:14 |
|
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 10:36 |
|
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
>
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 #989472 is a reply to message #989466] |
Thu, 06 December 2012 11:07 |
|
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 #989735 is a reply to message #989424] |
Fri, 07 December 2012 13:12 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
Goto Forum:
Current Time: Thu Apr 18 12:03:21 GMT 2024
Powered by FUDForum. Page generated in 0.02887 seconds |
] 
Search
Help
Register
Login
Home
