Community
Participate
Working Groups
Build Identifier: This problem occurs under Indigo; I could not reproduce it under Helios. The problem can be illustrated as follows: (1) Start Eclipse pointing to a new, empty workspace. (2) Turn "Build Automatically" off, close the Component Explorer View, show the Console view. At this point, the target platform has defaulted to the running platform. (3) Create a new general project called tp. (4) Create a new, empty target definition in the tp project. (5) Edit the target definition, adding a directory location of ${project_loc:tp}. (6) Save and close the definition (7) At Windows --> Preferences, set the target to the new defintion. Now open a suitable CQuery and "resolve and materialize". We get the following error: WARNING [0058] : Component request org.junit:osgi.bundle/[4.8.2.v4_8_2_v20110321-1705,4.8.2.v4_8_2_v20110321-1705] is inconflict with request org.junit:osgi.bundle/[3.8.2.v3_8_2_v20100427-1100,3.8.2.v3_8_2_v20100427-1100] ERROR [0063] : No suitable provider for component org.eclipse.ui.views.properties.tabbed:osgi.bundle/[3.5.200.I20110201-0800,3.5.200.I20110201-0800] was found in resourceMap http://www.opengda.org/buckminster/base/core.rmap ERROR [0063] : No suitable provider for component org.eclipse.ui.views.properties.tabbed:osgi.bundle/[3.5.200.I20110201-0800,3.5.200.I20110201-0800] was found in searchPath eclipse ERROR [0063] : Rejecting provider p2(${Eclipse_origin_selected}/eclipse/updates/3.6[http://download.eclipse.org/eclipse/updates/3.6]): No component match was found ERROR [0063] : Rejecting provider p2(${Eclipse_origin_selected}/releases/helios[http://download.eclipse.org/releases/helios]): No component match was found Errors and Warnings W [0058] : Component request org.junit:osgi.bundle/[4.8.2.v4_8_2_v20110321-1705,4.8.2.v4_8_2_v20110321-1705] is inconflict with request org.junit:osgi.bundle/[3.8.2.v3_8_2_v20100427-1100,3.8.2.v3_8_2_v20100427-1100] E [0063] : No suitable provider for component org.eclipse.ui.views.properties.tabbed:osgi.bundle/[3.5.200.I20110201-0800,3.5.200.I20110201-0800] was found in searchPath eclipse E [0063] : Rejecting provider p2(${Eclipse_origin_selected}/eclipse/updates/3.6[http://download.eclipse.org/eclipse/updates/3.6]): No component match was found E [0063] : Rejecting provider p2(${Eclipse_origin_selected}/releases/helios[http://download.eclipse.org/releases/helios]): No component match was found The exact component it fails on varies from attempt to attempt. Note that we don't have any unusual overrides in our CQuery. Re-resolving the CQuery fails in the same way. Refreshing (reload) the target defintion, and doing Windows --> Preferences --> Buckminster --> "refresh meta-data" still does not fix the probem. Simply restarting Eclipse does however solve the problem, and the materialization then works. My impression is that Buckminster does not correctly recognise when the target platform changes. Evidence for this can be seen by going to Window / Preferecnes / Buckminster after you have chanegd teh target, and clickign "refresh matadata". You get a bunch of errors: Problems during metadata refresh E No component named org.eclipse.ui.source:osgi.bundle/[3.7.0.I20110602-0100,3.7.0.I20110602-0100] is known to Buckminster (etc etc) We found the workaround (restart Eclipse) after banging our heads for several hours! Reproducible: Always
The problem we're facing is that there's no way to listen to target platform modifications. We could of course clear all cached data periodically but that would make a lot of things sluggish in the IDE.
(In reply to comment #1) > The problem we're facing is that there's no way to listen to target platform modifications. Ok, that explains it. I will update our internal developer documentation to reflect this, so people don't get caught out. One question: I was unable to reproduce the problem under Helios - did something change between the releases? Also, Windows --> Preferences --> Buckminster --> "refresh meta-data" does not appear to make Buckminster refresh its cached state of the target platform (only restarting Eclipse will do that). So, the real bug is: "Buckminster refresh meta-data does not refresh the target platform state". Thanks
(In reply to comment #1) > The problem we're facing is that there's no way to listen to target platform > modifications. We could of course clear all cached data periodically but that > would make a lot of things sluggish in the IDE. I ran into the same problem and it would be really nice to e able to tell Buckminster that one did change the TP without having to restart. An entry in the bucknminster context menu like "refresh/update target platform" could do the trick.
Evaluating Eclipse 3.7.1 for our development environment & ran into this same issue. We depend on Buckminster a great deal, cannot recommend Eclipse 3.7 to the rest of my team until this is fixed.
(In reply to comment #4) > Evaluating Eclipse 3.7.1 for our development environment & ran into this same > issue. We depend on Buckminster a great deal, cannot recommend Eclipse 3.7 to > the rest of my team until this is fixed. Indeed, our experience with 3.7.1, and Buckminster in particular, is that overall it is more stable and reliable that earlier releases - depite this bug. I can recommend 3.7.1 with the latest Buckminster.
(In reply to comment #4) > ... cannot recommend Eclipse 3.7 to > the rest of my team until this is fixed. Change of target platform has never worked in a satisfying manner, see comment #1, so I don't think this bug should prevent you from upgrading.
For my own development, this is the kind of glitch I can easily overlook as I understand Buckminster quite well. Most of the other developers on my team are vanilla Java devs, not familiar with Eclipse platform. If I give them a development environment, they expect everything to work as expected. If it doesn't, I will end up hand-holding when the Buckminster log shows a bunch of red errors. Even if I tell them it's normal and they should restart Eclipse after setting the target. And I don't want to have to tell them to restart Eclipse. It won't inspire much confidence in the tools I'm giving them. So you see, for us it's usability issue which prior versions of Buckminster do not seem to have. I'm sure the rest of Buckminster is much improved (which is why I'd really like to use it). I don't mean to sound ungrateful... Buckminster has done amazing wonders for my team's productivity. All our developers can spin an RCP product build directly from the IDE, using the exact same code paths and processes as the automated build. We have not seen automated build-specific problems since migrating away from PDE Build, which used to be a constant source of frustration. I'm really hoping this can be addressed in some way in 3.7.2. At the very least, a Buckminster menu item to tell it to re-read the target. Of course, getting an automatic notification from PDE would be better :)
(In reply to comment #7) > So you see, for us it's usability issue which prior versions of Buckminster do > not seem to have. Sure it does. For some reason you just haven't encountered it yet.
In case it is not already obvious, there is very little Buckminster can do except restart eclipse when shit has hit the fan. For reasons unknown, and outside of Buckminster's control what appears to be simple changes to the TP does not take effect, or makes Eclipse misbehave. *These occur even if you are not using Buckminster*. Totally agree that it sucks. If there was a way for us to fix what was wrong by some magic in Buckminster, believe me we would already have done so. As an example since it does not help to just refresh/reload the TP in many/most? cases, there is not all that much point calling it as you are almost certain in need of an Eclipse restart - it only makes it take much longer as it is first loaded with incorrect effect, and then loaded and applied correctly on restart. (Just my personal experience). Not sure what we can do to help the group of people that work with the TP/PDE fix the real underlying problems. Thomas are you aware of reported bugs that people could go vote on and voice their opinion, to perhaps get these issues fixed.
