Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313922

Summary: empty 'Plug-in Dependencies' after checking out "org.eclipse.jdt.apt.core"
Product: [Eclipse Project] PDE Reporter: Darin Wright <darin.eclipse>
Component: UIAssignee: Darin Wright <darin.eclipse>
Status: VERIFIED FIXED QA Contact:
Severity: critical    
Priority: P1 CC: ankur_sharma, curtis.windatt.public, daniel_megert, jean-michel_lemieux, john.arthorne, markus.kell.r
Version: 3.6Flags: curtis.windatt.public: review+
ankur_sharma: review+
john.arthorne: review+
daniel_megert: review-
Target Milestone: 3.6 RC3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
patch none

Description Darin Wright CLA 2010-05-21 11:08:53 EDT
3.6 RC2

* From the plug-ins view, I checked "org.eclipse.jdt.apt.core" out from HEAD (Import As -> Project from Repository..."
* The project ended up with an empty 'Plug-in Dependencies' classpath container and a bunch of compilation errors.
* Close/re-open of the project did not fix the problem
* Deleting and re-importing from the CVS perspective did not fix the problem
* Re-starting the workspace fixed the problem

After re-starting, deleting and re-importing also worked. So I don't have exact steps to reproduce.
Comment 1 Darin Wright CLA 2010-05-25 14:44:50 EDT
I saw something similar where I import org.eclipse.pde.build from CVS and all dependent PDE bundles ended up with empty/missing required plug-ins and compilation errors.
Comment 2 Darin Wright CLA 2010-05-26 16:27:52 EDT
I think I've discovered the root cause of this problem. The new support in BundleLauncherHelper for feature based launching was creating a new PluginModelManager. This is a singleton object that should not be instantiated... it should be retrieved through PDECore. It effectively registered seonday model event listeners (one for each feature launch) that attempted to update Java build paths in response to model events, but was basing the events on a different state.
Comment 3 Darin Wright CLA 2010-05-26 16:29:06 EDT
Created attachment 170097 [details]
patch
Comment 4 Darin Wright CLA 2010-05-26 16:34:59 EDT
Steps to reproduce:

* Launch an Eclipse Application using feature based launch
* Exit the target workbench
* Delete a plug-in project in your workspace - all dependents are now broken.
Comment 5 Ankur Sharma CLA 2010-05-26 16:39:52 EDT
Should we also make PluginModelManager singleton?
Comment 6 Darin Wright CLA 2010-05-26 16:46:03 EDT
(In reply to comment #5)
> Should we also make PluginModelManager singleton?

It is a singleton, to be accessed via:

* org.eclipse.pde.internal.core.PDECore.getModelManager()

However, in this case we can use existing API for the patch.
Comment 7 Ankur Sharma CLA 2010-05-26 16:56:35 EDT
+1
Comment 8 Darin Wright CLA 2010-05-26 16:58:46 EDT
(In reply to comment #4)
> Steps to reproduce:
> * Launch an Eclipse Application using feature based launch
> * Exit the target workbench
> * Delete a plug-in project in your workspace - all dependents are now broken.

The feature based launch I was using had all workspace features checked. I also added two example plug-ins (workspace projects) - "org.eclipse.debug.examples.core" and "org.eclipse.debug.examples.ui".
Comment 9 Curtis Windatt CLA 2010-05-26 22:32:53 EDT
+1 Patch makes a lot of sense, there is no benefit to us creating our own manager.  With the additional instructions I was finally able to reproduce the problem in my target workspace and the fix is good.

Fixed in HEAD.
Comment 10 Dani Megert CLA 2010-05-27 07:01:25 EDT
Sorry guys, this is causing major issues: After switching to I20100526-1625 where this fix came in, each time we import all our binary bundles the workspace is full of errors (no log entry) and clean+build doesn't make them go away. Only going back to I20100523-0800 and re-importing fixes the errors (building alone does not do the trick). Moving forward to I20100526-1625 reveals the problem again. Those code changes seem to bring the workspace in broken state and they are the only relevant ones since I20100523-0800.

-1 for RC3.
Comment 11 Darin Wright CLA 2010-05-27 09:45:03 EDT
Dani - This code is onlt executed when using feature based launch... I don't think this can be causing an import problem.
Comment 12 Dani Megert CLA 2010-05-27 09:46:01 EDT
Strange. What else then? Any idea?
Comment 13 Dani Megert CLA 2010-05-27 09:50:24 EDT
That was the only change I saw that made sense and I quickly checked that this class is used by the importer.
Comment 14 Darin Wright CLA 2010-05-27 09:55:19 EDT
As well... this fix was not in the 1625 build. It was introduced into the 2010-27-0100 build.
Comment 15 Dani Megert CLA 2010-05-27 09:58:21 EDT
>As well... this fix was not in the 1625 build. It was introduced into the
>2010-27-0100 build.
I only looked at the tag on the CU which said 'v20100526'.

Marking fixed again. Will have to report a new bug then.
Comment 16 Dani Megert CLA 2010-05-27 11:37:04 EDT
>Will have to report a new bug then.
Interested parties follow bug 314706.
Comment 17 Darin Wright CLA 2010-05-28 10:49:23 EDT
Verified in I20100527-1700