Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » Buckminster reports error when assembling fragment
Buckminster reports error when assembling fragment [message #653745] Thu, 10 February 2011 22:54 Go to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
HI,

I'm using an API [org.eclipse.swt.browser.Browser#getText(). ] that clearly exists in the platform source code (i.e. org.eclipse.swt.cocoa.macosx.x86_64_3.7.0.v3721b) and compiles and builds just fine under workspace PDE. I fact, it built fine in another plugin under Buckminster. But for one suage it is failing, claiming that:

Error: file ...Foo.java, line 137: The method getText() is undefined for the type Browser

The only thing unusual is that the library is restricted, i.e. "inaccessible", but of course it is assessable given that I can compile against it So somehow it looks like Buckminster is being more conservative here than PDE..how can I force it not to be?

thanks,

Miles
Re: Buckminster reports error when assembling fragment [message #653750 is a reply to message #653745] Thu, 10 February 2011 23:18 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Miles,

The most likely cause for this is that the workspace that Bucky uses has more restrictive compiler settings than you
have when you compile in the IDE (I use the term IDE, instead of PDE. I guess that's what you meant. PDE is always used,
both by Bucky and in the IDE).

If that's the case, then the remedy is to create a workspace template with the correct settings. Just start your IDE on
a brand new workspace, apply all settings that you want to the compiler, exit your IDE and then create a zip from the
workspace. When building headlessly, start by unzipping that workspace and then have Bucky use it for the build (-data
option).

HTH,
- thomas


On 2011-02-10 23:54, Miles Parker wrote:
> HI,
>
> I'm using an API [org.eclipse.swt.browser.Browser#getText(). ] that clearly exists in the platform source code (i.e.
> org.eclipse.swt.cocoa.macosx.x86_64_3.7.0.v3721b) and compiles and builds just fine under workspace PDE. I fact, it
> built fine in another plugin under Buckminster. But for one suage it is failing, claiming that:
>
> Error: file ...Foo.java, line 137: The method getText() is undefined for the type Browser
>
> The only thing unusual is that the library is restricted, i.e. "inaccessible", but of course it is assessable given that
> I can compile against it So somehow it looks like Buckminster is being more conservative here than PDE..how can I force
> it not to be?
>
> thanks,
>
> Miles
Re: Buckminster reports error when assembling fragment [message #653800 is a reply to message #653750] Fri, 11 February 2011 09:47 Go to previous messageGo to next message
Matthew Webber is currently offline Matthew WebberFriend
Messages: 198
Registered: December 2010
Senior Member
At our site we don't rely in the developers having the correct compiler settings for their workspace. Instead, we define all settings on a per-project basis - these are stored in various files in the project's .setttings directory. This is then checked in to version control, so at checkout time everyone is guaranteed to have the same setttings - this includes checkouts done by headless builds.

Additionally, we specify javacProjectSettings=true in each project's build.properties so that headless builds use the same settings as the IDE.

And then one of my nightly build jobs checks that every plugin is set up correctly according to the above ...

A similar approach might work for you.

Matthew Webber
Re: Buckminster reports error when assembling fragment [message #653903 is a reply to message #653800] Fri, 11 February 2011 18:39 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Hi Matthew,

Yes I like that approach much better in terms of maintenance then the suggestion to copy the workspace over -- that one seems like trouble to me somehow..

Matthew Webber wrote on Fri, 11 February 2011 04:47
At our site we don't rely in the developers having the correct compiler settings for their workspace. Instead, we define all settings on a per-project basis - these are stored in various files in the project's .setttings directory. This is then checked in to version control, so at checkout time everyone is guaranteed to have the same setttings - this includes checkouts done by headless builds.

Additionally, we specify javacProjectSettings=true in each project's build.properties so that headless builds use the same settings as the IDE.


Yes, on my projects I've actually been getting rid of those because I wanted people to be able to build according to their own setup, but I think your approach makes a lot more sense.

Quote:
And then one of my nightly build jobs checks that every plugin is set up correctly according to the above ...


If it isn't too much trouble could you post the actual script for that?
Re: Buckminster reports error when assembling fragment [message #653927 is a reply to message #653750] Fri, 11 February 2011 22:17 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Thomas Hallgren wrote on Thu, 10 February 2011 18:18

The most likely cause for this is that the workspace that Bucky uses has more restrictive compiler settings than you
have when you compile in the IDE


OK, I'm almost certain that I've ruled out this possibility. I put the most restrictive options on the build, causing it to fail, which allowed me to confirm that the jdt core settings I have:

org.eclipse.jdt.core.compiler.problem.discouragedReference=w arning
org.eclipse.jdt.core.compiler.problem.suppressOptionalErrors =enabled

Do allow it to compile. Looking at the error, it just doesn't look like a regular reported error, it looks like the builder is confused in some way. I think that it is not making some aspect of "restricted" classes available downstream. I know that there is some kind of weird issue with the getText method and different platforms -- I'm trying to track that down -- but that should be an issue here as I'm targeting the same platform as my IDE and the PDE build within that IDE.

Is there anything else that could be leaking in from the workspace? I'm assuming that the buckminster workspace should function exactly like any other new Eclipse workspace which leads me to think there is some kind of resolution (?) issue somewhere..
Re: Buckminster reports error when assembling fragment [message #653930 is a reply to message #653927] Fri, 11 February 2011 22:30 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Please also see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=337013
Re: Buckminster reports error when assembling fragment [message #653950 is a reply to message #653927] Sat, 12 February 2011 01:36 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
Is there a difference in how you setup/use the target platform perhaps?
Are you 100% sure the expected bundle/fragment is in the TP in both cases?

- henrik

On 2/11/11 11:17 PM, Miles Parker wrote:
> Thomas Hallgren wrote on Thu, 10 February 2011 18:18
>> The most likely cause for this is that the workspace that Bucky uses
>> has more restrictive compiler settings than you have when you compile
>> in the IDE
>
>
> OK, I'm almost certain that I've ruled out this possibility. I put the
> most restrictive options on the build, causing it to fail, which allowed
> me to confirm that the jdt core settings I have:
>
> org.eclipse.jdt.core.compiler.problem.discouragedReference=w arning
> org.eclipse.jdt.core.compiler.problem.suppressOptionalErrors =enabled
>
> Do allow it to compile. Looking at the error, it just doesn't look like
> a regular reported error, it looks like the builder is confused in some
> way. I think that it is not making some aspect of "restricted" classes
> available downstream. I know that there is some kind of weird issue with
> the getText method and different platforms -- I'm trying to track that
> down -- but that should be an issue here as I'm targeting the same
> platform as my IDE and the PDE build within that IDE.
>
> Is there anything else that could be leaking in from the workspace? I'm
> assuming that the buckminster workspace should function exactly like any
> other new Eclipse workspace which leads me to think there is some kind
> of resolution (?) issue somewhere..
Re: Buckminster reports error when assembling fragment [message #653960 is a reply to message #653950] Sat, 12 February 2011 03:42 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Henrik Lindberg wrote on Fri, 11 February 2011 20:36
Is there a difference in how you setup/use the target platform perhaps?
Are you 100% sure the expected bundle/fragment is in the TP in both cases?



The target platform is stock, i.e. I just do:

setpref targetPlatformPath="${WORKSPACE}/buildroot/target.platform"

I have exactly the same bundles in the TP, except that in addition to the osx 64 bundles there are all of the other platforms as well of course. The browser code compiles just fine except for this one method. Note that the import if for org.eclipse.ui.browser, but the actual bundle is e.g. org.eclipse.swt.cocoa.macosx_3.7.0. It is possible that for some target this method doesn't exist for some platforms, but I know it does for the targetted platform. I tired this both with a "build" and a perform, i.e.:

perform '-D' 'cbi.include.source=false' '-D' 'target.os=macosx' '-D' 'target.ws=cocoa' '-D' 'target.arch=x86_64' 'myapp#site.p2'
Re: Buckminster reports error when assembling fragment [message #653964 is a reply to message #653960] Sat, 12 February 2011 05:23 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Miles,

The org.eclipse.swt.cocoa.macosx_3.7.0 is for x86, so you're out of luck with that one. What you need is
org.eclipse.swt.cocoa.macosx.x86_64_3.7.0.v3721b.jar. I do find that bundle in the latest M5 milestone. What repository
are you using when you resolve? I looked at:

http://download.eclipse.org/eclipse/updates/3.7milestones/S- 3.7M5-201101272034

- thomas


On 2011-02-12 04:42, Miles Parker wrote:
> Henrik Lindberg wrote on Fri, 11 February 2011 20:36
>> Is there a difference in how you setup/use the target platform perhaps?
>> Are you 100% sure the expected bundle/fragment is in the TP in both cases?
>
>
> The target platform is stock, i.e. I just do:
>
> setpref targetPlatformPath="${WORKSPACE}/buildroot/target.platform"
>
> I have exactly the same bundles in the TP, except that in addition to the osx 64 bundles there are all of the other
> platforms as well of course. The browser code compiles just fine except for this one method. Note that the import if for
> org.eclipse.ui.browser, but the actual bundle is e.g. org.eclipse.swt.cocoa.macosx_3.7.0. It is possible that for some
> target this method doesn't exist for some platforms, but I know it does for the targetted platform. I tired this both
> with a "build" and a perform, i.e.:
>
> perform '-D' 'cbi.include.source=false' '-D' 'target.os=macosx' '-D' 'target.ws=cocoa' '-D' 'target.arch=x86_64'
> 'myapp#site.p2'
Re: Buckminster reports error when assembling fragment [message #653966 is a reply to message #653964] Sat, 12 February 2011 06:04 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Thomas Hallgren wrote on Sat, 12 February 2011 00:23
H
The org.eclipse.swt.cocoa.macosx_3.7.0 is for x86, so you're out of luck with that one. What you need is
org.eclipse.swt.cocoa.macosx.x86_64_3.7.0.v3721b.jar.


No that is the one I'm using..I just stupidly left the x86 part off. Again the weird thing is that it complies fine if I just take that one method reference away.
Re: Buckminster reports error when assembling fragment [message #653981 is a reply to message #653966] Sat, 12 February 2011 11:55 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Does this happen only for the cocoa.macosx.x86_64 combination or can you reproduce it for other platforms as well?

Not that it should matter, but on what platform does the build take place?

On 2011-02-12 07:04, Miles Parker wrote:
> Thomas Hallgren wrote on Sat, 12 February 2011 00:23
>> H
>> The org.eclipse.swt.cocoa.macosx_3.7.0 is for x86, so you're out of luck with that one. What you need is
>> org.eclipse.swt.cocoa.macosx.x86_64_3.7.0.v3721b.jar.
>
>
> No that is the one I'm using..I just stupidly left the x86 part off. Again the weird thing is that it complies fine if I
> just take that one method reference away.
Re: Buckminster reports error when assembling fragment [message #654160 is a reply to message #653903] Mon, 14 February 2011 12:46 Go to previous messageGo to next message
Matthew Webber is currently offline Matthew WebberFriend
Messages: 198
Registered: December 2010
Senior Member
I use a python script. It's a little too specific to our site to be useful without modification (there are various exception cases), but I've extracted the relevant code, which might be useful as a starting point:

    def test_plugins_build_properties(self):
        """ Checks that all plugins directories have a valid build.properties
            Run from <anything>/builder/build_utilities/<name>.py, processes <anything>/plugins/<various>
        """

        # go through all the plugins and check that their build.properties
        valid_count = error_count = 0
        patterns = ("javacDefaultEncoding.. *= *(utf|UTF)-8", "javacSource *= *1.6", "javacTarget *= *1.6", "javacProjectSettings *= *true")
        patterns_re = map(re.compile, patterns)
        for plugin_name in self.plugin_names():
            if plugin_name in self.BUILD_PROPERTIES_IGNORE:
                continue
            build_properties = os.path.join(self.plugins_dir, plugin_name, self.BUILD_PROPERTIES_NAME)
            pattern_found = [False,] * len(patterns)
            if not os.path.isfile(build_properties):
                print "ERROR: file does not exist for plugin %s (%s)" % (plugin_name, build_properties)
                error_count += 1
            else:
                build_properties_file = open(build_properties)
                try:
                    for line in build_properties_file.readlines():
                        for (index, pattern) in enumerate(patterns_re):
                            # print "%s %s %s %s" % (plugin_name, line, patterns[index], pattern.match(line.strip())) 
                            pattern_found[index] = pattern_found[index] or bool(pattern.match(line.strip()))
                finally:
                    build_properties_file.close()
                if all(pattern_found):
                    valid_count += 1
                    print "Valid: %s %s" % (plugin_name, self.BUILD_PROPERTIES_NAME)
                else:
                    print "ERROR: %s %s missing components" % (plugin_name, self.BUILD_PROPERTIES_NAME)
                    error_count += 1

        print "Plugins with %s valid %s, invalid = %s" % (self.BUILD_PROPERTIES_NAME, valid_count, error_count)
        sys.stdout.flush()
        self.failIf(error_count, "Some plugins had invalid or missing %s" % self.BUILD_PROPERTIES_NAME)


Hope that helps.
Matthew Webber
Re: Buckminster reports error when assembling fragment [message #654247 is a reply to message #653981] Mon, 14 February 2011 17:56 Go to previous messageGo to next message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Thomas Hallgren wrote on Sat, 12 February 2011 06:55
Does this happen only for the cocoa.macosx.x86_64 combination or can you reproduce it for other platforms as well?

Not that it should matter, but on what platform does the build take place?


Looks like my original reply got lost.. It happens on at least the linux platform that my build host is on and so with my local build that means cocoa 64 and whatever the linux boxen are. I'll play around with some more options if posibble.
Re: Buckminster reports error when assembling fragment [message #654501 is a reply to message #654247] Wed, 16 February 2011 04:21 Go to previous message
Miles Parker is currently offline Miles ParkerFriend
Messages: 1341
Registered: July 2009
Senior Member
Miles Parker wrote on Mon, 14 February 2011 12:56

It happens on at least the linux platform that my build host is on and so with my local build that means cocoa 64 and whatever the linux boxen are. I'll play around with some more options if posibble.


Tried on win, win, x86 as well and no joy. For the time being, I'm punting and resorting to making the call using reflection. Razz So it isn't really urgent now, but hopefully we'll get to the bottom of it at some point.
Previous Topic:Getting other kind of files using maven, maven2 provider
Next Topic:Question about reader type
Goto Forum:
  


Current Time: Fri Mar 29 15:18:18 GMT 2024

Powered by FUDForum. Page generated in 0.03560 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top