Community
Participate
Working Groups
I had a working target platform (http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.target/org.eclipse.orion.target.target?id=233b3bf5322c2f3bf164c5f5029a44d52d4a49a1 ), and today after saving a .product file I suddenly get these errors: eclipse.buildId=4.4.0.I20140606-1215 java.version=1.7.0_51 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86_64 -data /opt/pwebster/workspaces/orion/ org.eclipse.pde.core Error Mon Jul 07 10:24:10 EDT 2014 The current target platform contains errors, open Window > Preferences > Plug-in Development > Target Platform for details. org.eclipse.core.runtime.CoreException: Problems occurred getting the plug-ins in this container at org.eclipse.pde.internal.core.PluginModelManager.getExternalBundles(PluginModelManager.java:604) at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:525) at org.eclipse.pde.internal.core.PluginModelManager.targetReloaded(PluginModelManager.java:473) at org.eclipse.pde.internal.core.RequiredPluginsInitializer$1.run(RequiredPluginsInitializer.java:34) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Contains: Unable to locate installable unit org.eclipse.jgit Contains: Unable to locate installable unit org.eclipse.jgit Contains: Unable to locate installable unit org.eclipse.jgit Contains: Unable to locate installable unit org.eclipse.jgit Contains: Unable to locate installable unit org.eclipse.jgit Contains: Unable to locate installable unit org.eclipse.jgit org.eclipse.pde.core Error Mon Jul 07 10:24:10 EDT 2014 Problems occurred getting the plug-ins in this container org.eclipse.pde.core Error Mon Jul 07 10:24:10 EDT 2014 Unable to locate installable unit org.eclipse.jgit
Going to the target platform in the preferences and editing, the target platform now loads. When I click OK, it's active and appears to be loaded. But all of my projects have errors, and under Plug-in Dependencies they only show bundles from my workspace, not the target platform. How do I get them to refresh? PW
Created attachment 244876 [details] No error I dont get any error. When I copied pasted this in target file, the locations didnt load. So I increased the sequence number on line 1 <?xml version="1.0" encoding="UTF-8"?><?pde version="3.8"?><target name="org.eclipse.orion" sequenceNumber="10"> and it worked fine. I had to manually increase the sequence number since I manually added the contents. If done via editor, that should also have worked fine.
(In reply to Vikas Chandra from comment #2) > Created attachment 244876 [details] > No error > > I dont get any error. When I copied pasted this in target file, the > locations didnt load. So I increased the sequence number on line 1 > > <?xml version="1.0" encoding="UTF-8"?><?pde version="3.8"?><target > name="org.eclipse.orion" sequenceNumber="10"> Hi Vikas, thanks for looking into this. So if we increment the sequenceNumber to 10 it should just work? PW
The problem with the target platform is the minor part, going to the preferences got that to resolve. But PDE has wiped all of the Plug-in Dependencies from the plugin projects in the workspace, so that they can't see anything from the target platform. cleaning, restarting had no effect. But I switched back to the active platform, then back to the orion target, and the Plug-in Dependencies are back. PW
Did you happen to try the Reload button on the preference page? The reload button resolves the target and compares it what is currently in the PDE models. If they differ, it should kick off a target platform reset (same idea as changing to another target, then changing back). If reload doesn't fix the PDE models, this is a major bug. If reload does work, this bug is less severe. We should still be looking to help the user fix their problems (possibly automatically reloading the target). We have to be careful about blocking a workspace build operation, but perhaps when the PDE builder runs, if we see that there are errors in the backing target definition and 0 external target models, we can kick off a separate target reset job (or do a resolve and compare as the preference page button does).
When I opened my orion IDE today it was in the same broken state again, even though it was fine before I shut down last time. (In reply to Curtis Windatt from comment #5) > Did you happen to try the Reload button on the preference page? The reload button popped open an error dialog, complaining that it couldn't find jgit (basically it didn't contact the internet at all). I'm trying the switch target platform tricks again. PW
(In reply to Paul Webster from comment #6) > > I'm trying the switch target platform tricks again. That doesn't work, that target platform still has errors and complains about what it has available. PW
OK to get this to work: 1. edit the target in the pref page. - this seemed to cause it to check repos and URLs and turned it from errors into a tree that displayed all of the IU names. 2. hit OK 3. go back to the pref page and use Re-load. PW
I do not know what is causing you to have problems resolving the target. However it is a large p2 based target, so there are plenty of opportunities for problems (the jgit repo was questionable, but Paul told me that the url was updated to be a stable release repo). What PDE needs to do is allow users to recover from this state. Even when there is a failure to get one or more artifacts, the p2 slicer is more than happy to update the stored profile with what it did find. The target then sees that the profile sequence number matches and says 'all done'. If there is an error in the target, we should always attempt to resolve it. In 4.3, we always resolved on editor open. In addition the synchronize button would work as the existing models would not have required a resolved target.
(In reply to Paul Webster from comment #8) > OK to get this to work: > > 1. edit the target in the pref page. > - this seemed to cause it to check repos and URLs and turned it from errors > into a tree that displayed all of the IU names. > > 2. hit OK > > 3. go back to the pref page and use Re-load. > > PW Yes, you need to force a resolve. You can do this by changing the target locations or manually increasing the sequence number in the file. Then either pressing re-load on the pref page, or "Set as active target platform" in the editor should update the PDE models. I was going to suggest pressing the update button, however, that will only force a resolve if an IU version is updated.
http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=23660d70d901936e3803b196183e64a5204250c9 First step towards fixing this. With this change, if there is any problem while resolving the p2 contents of a target, the p2 profile will be deleted. This means that the next time the target is resolved (startup or editor opened or reload button pressed), the remote repositories will be contacted. I left a TODO in the change to try and only delete the sequence number property rather than the entire profile. This might allow us to avoid pinging remote repos if there was a local artifact problem. However, there is no way to modify the properties of an existing profile.
A couple issues with having a reload button: 1) Increasing the sequence number is not enough to force fetching from the remote repository. The cached profile checks if all settings and top level IUs match and if so, declare the cached profile as up to date. 2) Easiest way to kick off a resolve job and update the UI is to say the content changed. However, this also marks the editor/wizard as dirty. We will probably just have to have a flag to avoid marking as dirty. 3) If the target is set as the active target platform, should we reset the target platform on a reload? That is what we do when the update button is pressed (if the content was actually updated). Alternatively, we could use the same logic as the reload button on the main pref page that compares against the current target platform content before resetting. 4) The reload button on the preference page should be updated to also force a remote fetch.
I think it's important to have a reload capability to overcome p2 issues (eg., network connectivity, in-flight repository updates, etc.). I believe that increasing the sequence number is problematic in our use-case. Here is what we usually do: We have a global target definition shared in Git for all developers. Our target definition references a "nightly" repository. The IUs are listed using version "0.0.0" because we want PDE and Tycho to always fetch the latest available IUs. Developers are used to to refreshing the target definition on a regular basis. However, this refresh is a read-only operation to the target definition and it should (must) stay this way. Otherwise we probably end up with 50ish conflicting commits in Git/Gerrit for the target definition file each day.
(In reply to Curtis Windatt from comment #12) > A couple issues with having a reload button: > 1) Increasing the sequence number is not enough to force fetching from the > remote repository. The cached profile checks if all settings and top level > IUs match and if so, declare the cached profile as up to date. Between this and the sequence number changes causing conflicts in Git, the reload would have to do a p2 specific operation to delete the cached profile (not the downloaded bundles).
The fix to Bug 436950 - [target][p2] Update function of target editor does not doesn't seem to fix this. Also with the fix on comment 11, this problem still occurs. Please let me know if this is not the current status.
(In reply to Vikas Chandra from comment #15) > The fix to Bug 436950 - [target][p2] Update function of target editor does > not > doesn't seem to fix this. > > Also with the fix on comment 11, this problem still occurs. > > Please let me know if this is not the current status. What doesn't it fix? The fixes are not intended to fix the "Problems occurred getting..." error. That will happen if there is a p2 problem (in this case it couldn't find an IU for jgit). The fix is that opening the target file or restarting Eclipse will cause the target to retry connecting to the repositories, rather than looking at the cached p2 info (with errors) and saying that it's already finished.
By problem, I meant the problem of comment 0
The original issue where you could not fix a problematic p2 target location is fixed. I cloned to Bug 441190 to investigate the reload button later in 4.5.
*** Bug 430655 has been marked as a duplicate of this bug. ***
1) Create a target definition that uses a p2 repository, but don't let it download the content (you can copy the Orion one from git for example, or create one and cancel the resolve operation, or create it in one workspace and copy it to a new worksace) 2) Turn off your internet connection 3) Open the target and set it as the default target 4) Resolution will fail to find the necessary IUs (should have error on the target editor or in the log) 5) Shut down Eclipse, reconnect internet 6) Open Eclipse Target resolves ( Thanks Curtis for steps!!) Verified in Version: Mars (4.5) Build id: N20140901-2000
