Community
Participate
Working Groups
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.
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.
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.
Created attachment 170097 [details] patch
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.
Should we also make PluginModelManager singleton?
(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.
+1
(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".
+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.
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.
Dani - This code is onlt executed when using feature based launch... I don't think this can be causing an import problem.
Strange. What else then? Any idea?
That was the only change I saw that made sense and I quickly checked that this class is used by the importer.
As well... this fix was not in the 1625 build. It was introduced into the 2010-27-0100 build.
>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.
>Will have to report a new bug then. Interested parties follow bug 314706.
Verified in I20100527-1700
