[
https://issues.jboss.org/browse/JBIDE-8548?page=com.atlassian.jira.plugin...
]
Snjezana Peco commented on JBIDE-8548:
--------------------------------------
I suggest to remove this functionality to not muddy the waters and to
not steal 10 decent shortcut keys by default.
OK
But there are already are ways to attach shortcuts/keybindings to
"last launched" and you can also use the "favorites" menu entries to
make it even easier.
The user starts and stops remote configurations dynamically. He can never be sure that the
"last launched" configuration is the one he wants to start. This shortcut
won't help so much if the user has more remote applications. The plugin has been
created for those users that start/stop a lot of remote applications.
That's why "Always select the first one so you can always just press finish and
not have to click in the table" from your mockup won't be helpful. Every time
when calling the "Remote Java Application" action, the user will likely get
different remote applications and will have to review them in order to decide what of them
to start.
Would the "Remote Java Application..." dialog be started always when calling the
"Remote Java Application" action?
If so, the user will have to click the "Cancel" button every time when calling
this action and when he doesn't want the plugin to discover remote applications. If
not, we will have to add the "Discover Remote Application" action somewhere.
"The Finish button should do what it can to find matching
existing launch config so we don't create a new launch every time. i.e. look for port
connectiong to and project name. I believe run as junit have some similar search."
The plugin creates a configuration (the default) the first time when calling an action and
doesn't create it again. However, the plugin has to change some configuration
attributes: the selected projects, port ... If those attributes are the same as the
attributes of the previous launch configuration, nothing will be changed.
The user can configure some additional configurations with different source attachments,
the plugin will use the one that the user marked as the default (see the 8548-1.png
screenshot).
I understand why you want we to remove the "Remote Debug As" menu. However, now
the user has to click many times to start a launch configuration: start the action,
potentially cancel the "Remote Java Application..." progress dialog, select the
configuration in the "Remote Java Application..." dialog, click Finish. The
"Automatically connect if only one application found" checkbox won't help.
Users that debug only one application doesn't need this plugin at all. They can create
the standard Eclipse Remote Java Application configuration for that application.
The remote debug plugin is intended for those users that use a lot of launch
configurations. Aslak says, he uses two app servers, 2 eclipse, a few servlet containers
and some maven builts...
What is your opinion about adding the "Disable Remote Debug As menu" preference
(true by default)? The "Remote Debug As" menu wouldn't be shown by default
and the remote debug plugin wouldn't be started. Those users that want to use this
plugin, would have to enable this property, and only in that case this menu would be
shown.
Support auto discovery of remote processes for debugging
--------------------------------------------------------
Key: JBIDE-8548
URL:
https://issues.jboss.org/browse/JBIDE-8548
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: JBossAS
Reporter: Aslak Knutsen
Assignee: Snjezana Peco
Fix For: 3.3.0.M3, 3.3.x
Attachments: 8548-1.png, 8548-2.png, 8548-3.png, jbide-8548d.png, lsof.txt,
org.jboss.tools.remote.debug.zip, org.jboss.tools.remote.debug1.zip,
org.jboss.tools.remote.debug2.zip, remote_java_application.bmml
It would be helpful if Eclipse could provide a 'debug as' with auto discover of
local java processes, somewhat like jconsole does. Eclipse should also auto associate the
debug session with the current project.
'debug as' -> 'remote process x'
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira