Community
Participate
Working Groups
1) in a self hosting workspace 2) make a modification to a plugin 3) launch the workspace using the workspace launcher ->the modification isn't executed instead the run-time version of the plugin is run. If this problem wasn't already reported I can provide more details.
Please provide more details.
Since this bug wasn't reported before I wanted to check whether it only happens in my workspace. We have observed the same behaviour in Martin's workspace. There was also a post on the newsgroup mentioning this problem. My workspace is the existing development workspace (ws0321): - verified that the launch config has disabled all external plugins. - verified that the plugin path available from the launch config points into the workspace (ws0321). The configuration passed to the launch follows below. If I read the file properly than the plugin I modified (org.eclipse.jdt.junit) is taken from the workspace. stamp=1019310183420 stamp.features=0 stamp.plugins=1019310183420 bootstrap.org.eclipse.core.boot=file:d:/eclipse/ws0321/plugins/org.eclipse.core. boot/ feature.0.id=org.eclipse.platform feature.0.primary=true feature.0.version=2.1.0 feature.0.root.0=file:d:/eclipse/ws0321/plugins/org.eclipse.platform/ site.0.url=file:d:/eclipse/ws0321/ site.0.stamp=-1019806016905 site.0.stamp.features=0 site.0.stamp.plugins=1019310183420 site.0.updateable=true site.0.policy=USER-INCLUDE site.0.list.0=plugins/ZZZJunitTest/plugin.xml,plugins/org.apache.ant/plugin.xml, plugins/org.apache.lucene/plugin.xml,plugins/org.apache.xerces/plugin.xml,plugin s/org.demo.imageview/plugin.xml,plugins/org.eclipse.ant.core/plugin.xml,plugins/ org.eclipse.compare/plugin.xml,plugins/org.eclipse.contribution.junit/plugin.xml ,plugins/org.eclipse.contribution.junit.ui/plugin.xml,plugins/org.eclipse.contri bution.review/plugin.xml site.0.list.1=plugins/org.eclipse.contribution.spider/plugin.xml,plugins/org.ecl ipse.core.boot/plugin.xml,plugins/org.eclipse.core.resources/plugin.xml,plugins/ org.eclipse.core.runtime/plugin.xml,plugins/org.eclipse.debug.core/plugin.xml,pl ugins/org.eclipse.debug.ui/plugin.xml,plugins/org.eclipse.help/plugin.xml,plugin s/org.eclipse.help.appserver/plugin.xml,plugins/org.eclipse.help.ui/plugin.xml,p lugins/org.eclipse.jdt/plugin.xml site.0.list.2=plugins/org.eclipse.jdt.core/plugin.xml,plugins/org.eclipse.jdt.de bug/plugin.xml,plugins/org.eclipse.jdt.debug.ui/plugin.xml,plugins/org.eclipse.j dt.doc.isv/plugin.xml,plugins/org.eclipse.jdt.doc.user/plugin.xml,plugins/org.ec lipse.jdt.junit/plugin.xml,plugins/org.eclipse.jdt.launching/plugin.xml,plugins/ org.eclipse.jdt.source/plugin.xml,plugins/org.eclipse.jdt.ui/plugin.xml,plugins/ org.eclipse.jdt.ui.examples.projects/plugin.xml site.0.list.3=plugins/org.eclipse.jdt.ui.tests/plugin.xml,plugins/org.eclipse.jf ace/plugin.xml,plugins/org.eclipse.jface.text/plugin.xml,plugins/org.eclipse.pde /plugin.xml,plugins/org.eclipse.pde.build/plugin.xml,plugins/org.eclipse.pde.cor e/plugin.xml,plugins/org.eclipse.pde.doc.user/plugin.xml,plugins/org.eclipse.pde .junit/plugin.xml,plugins/org.eclipse.pde.runtime/plugin.xml,plugins/org.eclipse .pde.ui/plugin.xml site.0.list.4=plugins/org.eclipse.platform/plugin.xml,plugins/org.eclipse.search /plugin.xml,plugins/org.eclipse.swt/plugin.xml,plugins/org.eclipse.team.core/plu gin.xml,plugins/org.eclipse.team.cvs.core/plugin.xml,plugins/org.eclipse.team.cv s.ui/plugin.xml,plugins/org.eclipse.team.extras/plugin.xml,plugins/org.eclipse.t eam.ui/plugin.xml,plugins/org.eclipse.test/plugin.xml,plugins/org.eclipse.text/p lugin.xml site.0.list.5=plugins/org.eclipse.tomcat/plugin.xml,plugins/org.eclipse.ui/plugi n.xml,plugins/org.eclipse.ui.editors/plugin.xml,plugins/org.eclipse.ui.examples. javaeditor/plugin.xml,plugins/org.eclipse.ui.externaltools/plugin.xml,plugins/or g.eclipse.ui.views/plugin.xml,plugins/org.eclipse.ui.workbench/plugin.xml,plugin s/org.eclipse.ui.workbench.texteditor/plugin.xml,plugins/org.eclipse.update.core /plugin.xml,plugins/org.eclipse.update.ui.forms/plugin.xml site.0.list.6=plugins/org.junit/plugin.xml,plugins/org.eclipse.core.resources.wi n32/fragment.xml,plugins/org.eclipse.swt.win32/fragment.xml,plugins/org.eclipse. ui.win32/fragment.xml,plugins/org.eclipse.update.core.win32/fragment.xml eof=eof
Your observation is correct - the configuration file looks good - all the plug- ins passed to the run-time workbench are coming from one place i.e. your workspace (d:/eclipse/ws0321/).
Did you try to reproduce the problem in an existing workspace? Since everybody here is observing this problem I was wondering what the difference in the set-up is.
Tried to remove the .config folder but it has no impact.
I have the same problem as is described here when I import existing plugins from a product that is built on eclipse and then self-host. Creating a new workspace didn't help, but when I went back to the M3 driver, the problem went away. I think this problem started around the M5 driver. I also found in the M5 driver that in some classes things worked fine, but in some classes in the same plugin, although my changes were being executed, when a breakpoint was reached, the PDE would open a new editor with the "attach source" button (it seemed to be looking in my workspace for execution, but in the plugins for showing source). I have only had problems with plugins in my workspace that are dependencies of plugins that are not in my workspace.
Could it be that PDE is running the correct code but the source locator is showing the wrong source?
In my case it is running the wrong code, i.e., I can put in a sysout println and it isn't executed.
I should have mentioned that when I was using the M5 driver, I was working with different plugins. When using both RCx drivers, I had a fresh workspace and imported a completely different set of plugins - in that case my workspace changes weren't picked up no matter what I did (until I went back to M3) - so in that case it wasn't just the source not being located. I haven't had a chance to see what happens when I import the plugins I was using in M5 into an RC2 driver though (I can't remember which classes had breakpoints that hit the problem I mentioned).
Did you reimport all the binary projects from RC2? I think I am closing on the problem - in RC2 we changed the version of the configuration file (as a result of an unrelated blocker fix we propagated from our 2.0.3 work). Since PDE creates a temp. configuration when launching the second instance, we have a problem whereby RC1 boot can only handle configurations with version 1.0, while RC2 boot expects version 2.1 (and PDE in RC2 creates 2.1 configurations). Please verify you have RC2 boot in your workspace.
I may not fuly understand how the workspace works, but I have observed something that might help in this investigation. I have the workspace that I use with each new stable release. When I switched to RC2 I did not observe the bug 34169 and JUnit wizard was working fine (and it shouldn't due to the bug introduced in RC2 in JUnitWizard.java). Which means it was using the old binary from RC1 or may be even from M5 or M4. I did find reference to M4 in .metadata\.plugins\org.eclipse.jdt.ui\dialog_settings.xml in <item key="org.eclipse.jdt.ui.lastextjar value="C:\eclipse.M4 \plugins\org.eclipse.jface_2.1.0"/>. Then eclipse crashed (due to the fault of ru.nlmk.eclipse.plugins.profiler plugin when running "Run-time Workbench" profiling). The restart of eclipse trigerred "Refresh workbench" and THEN 34169 started to appear, which means correct RC2 binary was executing. I do not remember if the refresh was running when I switched to RC2 and I could not reproduce it. The cause for this behaviuor could be either one: - the refresh was not correctly trigerred (most probably) - if it was run then it was not complete. Looks like (comment #10) the first is the one to look at.
Our team member hit the same problem while trying to selfhost using RC2 and the workspace from RC1. He was able to work again when all the binary projects were re-imported. I think the only real issue (requiring code change) is when targeting products based on older releases (<=2.0.2). We switched the version in 2.0.3 so any platform with core boot version >=2.0.3 will work with configuration format version 2.1. We added this code today in time for build 20030312.
Approved for fixing in RC3
Confirmed that users can self-host using RC2. We also tested against 2.0.2 build and with the addition of the described fix, it works there too.
