Bug 323289

Comment 1 Curtis Windatt 2010-08-20 15:54:38 EDT

Are you using the official helios release?  I just want to make sure that the line numbers are accurate as there are a couple similar npes that have been fixed (such as bug 313409 fixed in 3.6.1).

I do see how we could end up with an NPE while looking up artifacts in the bundle pool. If the bundle pool directory has been deleted (or myabe if it wasn't created by p2 earlier in the resolve) the repo would be null.

Comment 2 Stephen McCants 2010-08-20 16:41:07 EDT

Yes, I'm using the official 3.6 release.

Where does the bundle pool directory exist?

Comment 3 Curtis Windatt 2010-08-20 16:45:50 EDT

(In reply to comment #2)
> Yes, I'm using the official 3.6 release.
> 
> Where does the bundle pool directory exist?

<workspace>/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool

Comment 4 Stephen McCants 2010-08-20 17:02:10 EDT

So, let us suppose that it some how got deleted in my current workspace (this workspace worked before this morning and started working again this afternoon).  Then creating a new workspace should have resolved the problem, right?

Unfortunately, when I tried creating a new workspace, the new workspace didn't work either.  Shortly after the old workspace started working (using 3.5.2, instead of 3.6), the new workspace (never touched by 3.5.2) started working too.  Now both workspaces work for 3.6.

Strange problem.

Comment 5 Tim Mok 2010-08-26 09:30:31 EDT

I just hit this too with the official 3.6 release.

I was changing target platforms and after applying the change my workspace started rebuilding. During this time, I switched target platforms and got the NPE while loading the new target. Whenever I try to load this target I get the NPE. Restarting does not resolve the problem. Creating a new workspace still results in a NPE.

I'm not sure why I would magically get the NPE unless the target platform switch while building corrupted my bundle pool. It doesn't really explain why a new workspace gets the same NPE. It's just this one target platform that doesn't work. If I use another one, it's fine.

I'm using target platform files explained here: https://jazz.net/wiki/bin/view/Main/DevSetupMain#Developing

Comment 6 Curtis Windatt 2010-09-01 16:18:00 EDT

Fixed in HEAD, see IUBundleContainer.java.  This won't make your bundle pool work if it has problems, but it will prevent the NPE and instead provide the actual error p2 is throwing.

Comment 7 Eric Jain 2011-03-23 19:07:29 EDT

I've run into this as well on 3.6.2, after manually clearing out the .bundle_pool. Workaround: Rename the target platform definition file and open it, at which point the bundle pool is repopulated and all appears to be fine...

Comment 8 Axel Uhl 2014-11-30 19:25:37 EST

I still see similar behavior on 4.4.0. Switching between two target definitions where one has a newer version of mockito eventually caused my .bundle_pool to end up to be inconsistent. I tried removing but then also ran into the problem of re-populating it. Reading the workaround that Eric had posted helped in my case: rename the .target file, set it as the target platform and watch the .bundle_pool fill up.

This seems pretty broken, still so many years after the issue was already described. Any ideas what a good fix could look like? I really suggest re-opening this bug.

Comment 9 Curtis Windatt 2014-12-01 11:23:02 EST

Reopening as requested.  Do you have additional information in the log?

Comment 10 Axel Uhl 2014-12-01 14:49:15 EST

One element I was able to see in the .log file that may be of interest was this:

!ENTRY org.eclipse.pde.core 4 0 2014-12-01 20:46:57.146
!MESSAGE The current target platform contains errors, open Window > Preferences > Plug-in Development > Target Platform for details.
!STACK 1
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.core.target.LoadTargetDefinitionJob.resetPlatform(LoadTargetDefinitionJob.java:229)
        at org.eclipse.pde.core.target.LoadTargetDefinitionJob.runInWorkspace(LoadTargetDefinitionJob.java:150)
        at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

I'll continue trying to reproduce.

Comment 11 Axel Uhl 2014-12-01 15:26:54 EST

It's fairly easy to reproduce the "rename-to-populate" behavior. When I remove .bundle_pool, reloading the target platform gives errors due to bundles not being found. Re-starting with -clean, renaming the .target file and setting that as the target platform properly loads the bundles into .bundle_pool each time I've tried. This in itself is a bit awkward as Eclipse would have to expect the directory to become inconsistent for any reason and should offer an intrinsic way to make the .bundle_pool consistent again. Explicitly reloading the target platform selected would be a good point in time to do so.

Comment 12 Axel Uhl 2014-12-01 15:34:48 EST

I now tried again to reproduce the problem with the mockito upgrade. I built a local p2 repository that has a newer version of mockito (1.10.14 instead of 1.9.5), then switched to a target definition that refers to the local repository using a file:// URL. The status bar said "loading target platform" but the new mockito JAR didn't make it into .bundle_pool where still only the old version resides. The .log file again has:

!ENTRY org.eclipse.pde.core 4 0 2014-12-01 21:32:18.330
!MESSAGE The current target platform contains errors, open Window > Preferences > Plug-in Development > Target Platform for details.
!STACK 1
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.core.target.LoadTargetDefinitionJob.resetPlatform(LoadTargetDefinitionJob.java:229)
	at org.eclipse.pde.core.target.LoadTargetDefinitionJob.runInWorkspace(LoadTargetDefinitionJob.java:150)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Contains: Required plug-in could not be found: org.mockito.mockito-core
Contains: Required plug-in could not be found: org.objenesis
!SUBENTRY 1 org.eclipse.pde.core 4 0 2014-12-01 21:32:18.330
!MESSAGE Problems occurred getting the plug-ins in this container
!SUBENTRY 2 org.eclipse.pde.core 4 100 2014-12-01 21:32:18.330
!MESSAGE Required plug-in could not be found: org.mockito.mockito-core
!SUBENTRY 2 org.eclipse.pde.core 4 100 2014-12-01 21:32:18.330
!MESSAGE Required plug-in could not be found: org.objenesis

Comment 13 Axel Uhl 2014-12-01 15:36:18 EST

An explicit "Reload" in the target platform settings dialog gives an error popup saying "Problems occurred getting the plug-ins in this container" listing the mockito-core and the objenesis bundles as "could not be found."

Comment 14 Axel Uhl 2014-12-01 15:38:52 EST

And, as before, renaming the .target file that points to the local file:// repository and then setting it using Window > Preferences > Plug-in Development > Target Platform immediately loads the new versions into .bundle_pool and the workspace build succeeds. The .log file does not provide any new messages for these actions.

Comment 15 Eclipse Genie 2019-10-08 16:59:34 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.