Community
Participate
Working Groups
I've got ~70 plugins under development; when starting run-time workbench, only one of the plugins is loaded (and no messages pointing that others have not been loaded due to some errors). Looks like plugins are not being loaded if their projects are not in default folder. I.e. in my situation only one plugin is resided in <eclipse>/workspace folder and it's loaded properly, when all others are imported from P4/CVS/... and just ignored on start of run-time workbench.
Forgot to mention: the problems appear only on M5 and is not reproducible with M4
I encountered a similar problem with the following configuration: eclipse install : c:\eclipse workspace : d:\myworkspace (it contains the plugin hello world) runtime-workspace : d:\myruntime-workspace When I start my runtime workbench, the hello world plugin is not found. The problem seems to come from the fact that eclipse and the runtime-workspace are not on the same drive.
On my configuration Eclipse is installed to e:\eclipse2.1 run-time workbench is default e:\eclipse2.1\runtime-workbench and sources are resided in e:\perforce and e:\cvs I.e. I've got problems even when workspace and sources are on the same drive.
I think both scenarios (same drive, different drive) are caused by the same bug that we fixed yesterday. Please try with the next integration build (0218) - I think it should work.
In version I20030218 it still doesn't work. Eclipse is installed to e:\eclipse2.1M5, target platform e:\eclipse2.0 In Plug-in paths I see: file:e:/eclipse2.1M5/workspace/com.borland.mpi/plugin.xml - this is the only plugin loaded from my dev environment file:e:/perforce/ts/ts.framework/dev/crs/_com.togethersoft.sapient.core/plugin. xml - this and other plugins from non-workspace location are not loaded and no error messages provided ... file:/e:/eclipse2.0/plugins/org.apache.ant_1.4.1/plugin.xml - this and other Eclipse plugins loaded properly. Here what I see in run-time workbench in Configuration details: *** Plugin Registry: com.borland.mpi (1.0.0) org.apache.ant (1.4.1) org.apache.lucene (1.2.0) org.apache.xerces (4.0.5) org.eclipse.ant.core (2.0.1) org.eclipse.compare (2.0.0) org.eclipse.core.boot (2.0.1) org.eclipse.core.resources (2.0.1) org.eclipse.core.resources.win32 (2.0.1) org.eclipse.core.runtime (2.0.1) org.eclipse.debug.core (2.0.0) org.eclipse.debug.ui (2.0.0) org.eclipse.draw2d (2.0.0) org.eclipse.draw2d.doc.isv (2.0.0) org.eclipse.gef (2.0.0) org.eclipse.gef.doc.isv (2.0.0) org.eclipse.gef.examples.logicdesigner (2.0.0) org.eclipse.help (2.0.1) org.eclipse.help.ui (2.0.1) org.eclipse.help.ui.win32 (2.0.1) org.eclipse.help.webapp (2.0.1) org.eclipse.jdt (2.0.1) org.eclipse.jdt.core (2.0.1) org.eclipse.jdt.debug (2.0.1) org.eclipse.jdt.debug.ui (2.0.1) org.eclipse.jdt.doc.isv (2.0.0) org.eclipse.jdt.doc.user (2.0.0) org.eclipse.jdt.junit (2.0.1) org.eclipse.jdt.launching (2.0.1) org.eclipse.jdt.source (2.0.1) org.eclipse.jdt.ui (2.0.1) org.eclipse.pde (2.0.1) org.eclipse.pde.build (2.0.0) org.eclipse.pde.core (2.0.1) org.eclipse.pde.doc.user (2.0.0) org.eclipse.pde.runtime (2.0.0) org.eclipse.pde.source (2.0.1) org.eclipse.pde.ui (2.0.1) org.eclipse.platform (2.0.1) org.eclipse.platform.doc.isv (2.0.0) org.eclipse.platform.doc.user (2.0.0) org.eclipse.platform.source (2.0.1) org.eclipse.platform.win32 (2.0.1) org.eclipse.platform.win32.source (2.0.1) org.eclipse.sdk.win32 (2.0.1) org.eclipse.search (2.0.1) org.eclipse.swt (2.0.1) org.eclipse.swt.win32 (2.0.1) org.eclipse.team.core (2.0.1) org.eclipse.team.cvs.core (2.0.0) org.eclipse.team.cvs.ssh (2.0.0) org.eclipse.team.cvs.ui (2.0.1) org.eclipse.team.ui (2.0.0) org.eclipse.tomcat (4.0.3) org.eclipse.ui (2.0.1) org.eclipse.ui.win32 (2.0.0) org.eclipse.ui.externaltools (2.0.1) org.eclipse.update.core (2.0.1) org.eclipse.update.core.win32 (2.0.0) org.eclipse.update.ui (2.0.1) org.eclipse.update.ui.win32 (2.0.0) org.eclipse.update.ui.forms (2.0.0) org.junit (3.7.0)
I also met this problem. I try to trace into the code of how the pde set the environment for loading plugins, and find that PDE generated a file as: C:\eclipse2.1.0\workspace\.metadata\.plugins\org.eclipse.pde.core\C__eclipse2.1.0_runtime-workspace\platform.cfg in this file, there is some content look like: site.0.list.0=voxa/myplugin/plugin.xml,....... My plugin is at: d:\voxa\myplugin But in the cfg file, the "d:\" drive is not there. And when I try debug, it will try to looking for the plugin at "c:\eclipse2.1.0\voxa\myplugin" and result in fail. This bug should change to P1.
OK, this makes sense - the separate drive was only part of the story. Your initial comment was absolutely right - I should have read it again :-). Here is how it works: Eclipse really loads using local 'sites' and features in them. Plug-ins are computed based on configured features. This process is performed by the Update component. Eclipse can have one or more local site where features and plug-ins are installed. In the platform configuration, site has the first part of the path, and all plug-ins that belong to it are listed relative to that path. When PDE launches Eclipse, it creates a transient configuration for that session only. Starting from the list of plug-ins (both in the workspace and in the target platform), it reverse-engineers 'fake' sites just so that it could add plug-ins relative to them. We made a mistake of assuming that all the workspace plug-ins are relative to the workspace root. This is not the case for every workspace plug-in project that has been created using the non-default path. When we used 'getLocation()' on the project instead, it worked. For testing, I created 'Hello, World' plug-in in 'c:\perforce' and 'Plug-in with a view' in 'c:\cvs', while my installation was in d:\eclipse- xxx\eclipse. Both plug-ins loaded correctly. Check the RC1 for the fix.
Please reopen this. I'm still seeing it on 200303132359 with the workspace, target, and platform all on the same drive.
If Nick, Pascal and Yang don't see this problem any more, yours must be something different. Please open a different defect instead of reopening this one (you can reference it if you want, though).
In RC1 the problem seemed to be fixed, however in RC2 a new one seem to appear, which was referred in #34296 (see comments #8 and #10). I believe the latter situation is closer to Nitin's one, Dejan, is there a bug number for the configuration fix you mentioned? I'm currently using 200303120800 (post-RC2 build), which works fine for me.
The problem you are describing may be related to configuration version change we made in RC2. RC2 is known to cause problems if target platform is an older driver (<RC2). Your experience with drivers newer than RC2 is consistent with this problem - we did fix is shortly after RC2.
