[
https://issues.jboss.org/browse/JBIDE-8548?page=com.atlassian.jira.plugin...
]
Max Rydahl Andersen commented on JBIDE-8548:
--------------------------------------------
> 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.
Only the first time - there after he can rerun it by simply giving it a name and put it
under favorites; the only "missing" element is the shortcut key.
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.
see above - and this is not unique for remote launches, its the *exact* same for normal
launches which are even more used thus I don't see the point for solving it here.
The plugin has been created for those >users that start/stop a lot
of remote >applications.
I don't see it that way - the plugin is created to allow easy creation of launch
config for remote processes - something most users only have 1 or 2 of; Aslak is a special
case ;)
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.
Why? if there only are *one* most of the time how can that not be helpful not having to
click an extra time ?
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.
That is only the case for when you have multiple which seriously is *not* the common case;
and even if it was you want to be able to just press finish and not *always* require
selecting one.
Would the "Remote Java Application..." dialog be started
always when calling the "Remote >Java Application" action?
I don't understand the question - why would it not ?
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.
If he just wants to run the existing launch why doesn't he just use that one directly
instead of going via remote debug as...?
And you can avoid this by providing a list of previous launched remote that the user can
launch and ignore the search.
> "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)
Currently it creates a custom type of launch - which really is not necessary and dilutes
the purpose imo.
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).
Marked as "default" is redundant - why is that there? Why not search the
existing remote launches and use that if it fits the same criteria ? i.e. project
selection, port etc. ?
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.
No, he doesn't. The last few launches shows up under launches so its trivial to rerun
using the exact same UI/concepts as already for normal launches.
And you can avoid the "having to cancel" by showing previous launches and let
user launch those directly if you want to.
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.
Untrue - creating a remote launch app requires me to click much more AND know the port
number to connect to. This remote debug launch is excellent for those with even just 1
remote process.
>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...
Yes, and he would be able to work with this new setup just as effectively as the submenu
approach which blocks the UI and is not consistent with rest of eclipse.
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.
I think that is fine to have as an option to remove it from the context menu if you dont
use it. but this really deserves to be enabled by default and under existing Debug As..
menu.
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