Community
Participate
Working Groups
I'm currently looking for an error that only occurs on another OS than the one I have installed on my laptop. To observe the problem I can just install the application inside a virtualization box such as VMware, which is fine. But... to do proper debugging of the problem, it gets very difficult. I can either install a full environment inside VMware in the target/guest OS - which due to licensing issues, is rather difficult in this case - or I can run the application with extra arguments for debugging (e.g. -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,address=nnnn,server=y,suspend=y) and then attach to the port via the Remote Java Application launch type. Unfortunately, whenever a change is made in the application, it has to be re-exported, which takes forever!!! The next option is to share the Eclipse workspace with the target/guest OS, and then run a Eclipse command on the target to execute the workspace plug-ins directly such in the same fashion as done by PDE. The command gets rather long and is difficult to manage as you can see here ...\target-platform\eclipse\eclipse.exe -product ... -data Z:\Eclipse\workspaces\runtime... -configuration file:Z:/Eclipse/workspaces/.../.metadata/.plugins/org.eclipse.pde.core/....product/ -dev file:Z:/Eclipse/workspaces/.../.metadata/.plugins/org.eclipse.pde.core/....product/dev.properties -startup Z:\...\target-platform\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar -os win32 -ws win32 -arch x86 -console -consoleLog -clean -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y What is worse, is the fact that we have to manually modify the bundle.list and config.ini files to map the the correct shared folder in the target/guest OS. But.. It seems to work. (You _just_ have to get the network connection between the host and the target/guest OS to work first... That turned out to be easy enough once I figured out how to disable the firewall :-)) --------------------------------- The worst part is that we see this more and more, as the products are released for more and more platforms. What I would love to see, is basically a way to automate the above. Two options comes to mind: - a new JRE VM Type (as installed with org.eclipse.jdt.launching.vmInstallTypes) that can automatically launch the application *inside* the VMware box. Unfortunate, this does not handle the various changes that has to be made in the files. - a new launch type (as installed with org.eclipse.debug.core.launchConfigurationTypes) that has an additional page, where you can setup additional information about the virtualization box and the mapping of file names needed... -- Configuration Details -- Product: Eclipse SDK 3.5.2.v201002111343 (org.eclipse.sdk.ide) Installed Features: org.eclipse.pde 3.5.2.R35x_v20100119-7Z7_FA2FDX-aXQYWqYDBz-z0qufo
Does the VMWare Eclipse Integrated Debugger cover you needs? http://www.vmware.com/pdf/ws7_eclipse_debug.pdf (In reply to comment #0) > I'm currently looking for an error that only occurs on another OS than the one > I have installed on my laptop. To observe the problem I can just install the > application inside a virtualization box such as VMware, which is fine. > > But... to do proper debugging of the problem, it gets very difficult. I can > either install a full environment inside VMware in the target/guest OS - which > due to licensing issues, is rather difficult in this case - or I can run the > application with extra arguments for debugging (e.g. -vmargs -Xdebug > -Xrunjdwp:transport=dt_socket,address=nnnn,server=y,suspend=y) and then attach > to the port via the Remote Java Application launch type. > > Unfortunately, whenever a change is made in the application, it has to be > re-exported, which takes forever!!! > > The next option is to share the Eclipse workspace with the target/guest OS, and > then run a Eclipse command on the target to execute the workspace plug-ins > directly such in the same fashion as done by PDE. The command gets rather long > and is difficult to manage as you can see here > > ...\target-platform\eclipse\eclipse.exe -product ... -data > Z:\Eclipse\workspaces\runtime... -configuration > file:Z:/Eclipse/workspaces/.../.metadata/.plugins/org.eclipse.pde.core/....product/ > -dev > file:Z:/Eclipse/workspaces/.../.metadata/.plugins/org.eclipse.pde.core/....product/dev.properties > -startup > Z:\...\target-platform\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar > -os win32 -ws win32 -arch x86 -console -consoleLog -clean -vmargs -Xdebug > -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y > > What is worse, is the fact that we have to manually modify the bundle.list and > config.ini files to map the the correct shared folder in the target/guest OS. > > But.. It seems to work. > > (You _just_ have to get the network connection between the host and the > target/guest OS to work first... That turned out to be easy enough once I > figured out how to disable the firewall :-)) > > --------------------------------- > > The worst part is that we see this more and more, as the products are released > for more and more platforms. > > What I would love to see, is basically a way to automate the above. Two options > comes to mind: > > - a new JRE VM Type (as installed with > org.eclipse.jdt.launching.vmInstallTypes) that can automatically launch the > application *inside* the VMware box. Unfortunate, this does not handle the > various changes that has to be made in the files. > > - a new launch type (as installed with > org.eclipse.debug.core.launchConfigurationTypes) that has an additional page, > where you can setup additional information about the virtualization box and the > mapping of file names needed... > > -- Configuration Details -- > Product: Eclipse SDK 3.5.2.v201002111343 (org.eclipse.sdk.ide) > Installed Features: > org.eclipse.pde 3.5.2.R35x_v20100119-7Z7_FA2FDX-aXQYWqYDBz-z0qufo
(In reply to comment #1) > Does the VMWare Eclipse Integrated Debugger cover you needs? > http://www.vmware.com/pdf/ws7_eclipse_debug.pdf As far as I can see, no. Two reasons: - it is part of the workstation product - not the player - and therefore costs money. Though that problem can be solved... - it does not seem to support launch of Eclipse/OSGi applications, only "plain" Java applications. The later item means you still have to "invent" the correct command line and fixed the files...
(In reply to comment #1) > Does the VMWare Eclipse Integrated Debugger cover you needs? > http://www.vmware.com/pdf/ws7_eclipse_debug.pdf I have now tested this "solution"... but it only does very little of what I want: I still have to manually modify the bundle.list and config.ini files to map the the correct shared folder in the target/guest OS. Which is the hard part :-)
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.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
