Re: [platform-debug-dev] Launch Configurations

[Dave_Dykstal@xxxxxxx]

Sorry, I can tend to ramble, but you did get the gist of the second 
question.

I think the notion of shared persistent properties is being looked at 
either in core or vcm (er, "team").  I've had to develop a mechanism, as 
have the JDT folks.  It would be nice if we all did it the same way.

Any idea of what attributes other than "shared" vs "local" would be common 
among launchers and so a part of the debug core?  It may be that this is 
it.

-- Dave






"Darin Wright/WPG/OTI" <Darin_Wright@xxxxxxx>
Sent by: platform-debug-dev-admin@xxxxxxxxxxx
11/26/2001 03:12 PM
Please respond to platform-debug-dev

 
        To:     platform-debug-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-debug-dev] Launch Configurations


Although the use cases in the document provided are Java specific, they 
are only examples. Launch configurations are generic - and can be 
applied/used by any language. (Sorry, there should have been a disclaimer 
in the document about this). The debug defines a "launch configuration" 
extension point to allow clients to write their own launch code as 
required - i.e. what executeables to launch, how to launch them, or to 
establish a remote connection - it's all up to the client.  The debug core 
will take care of persisting lanuch configuration data, which is simply 
key/value pairs for attributes (much like markers). The debug core also 
takes care of storing the configurations locally, or as shared files in a 
workspace. Clients control what data is stored in a launch configuration, 
and they are extensible. For example, the Java Debug launch configuration 
adds attributes to a configuration that describe the VM and program 
argument! s for a launch. The debug core delegates to clients to do th 
actual launching. 

There will also be a "launch configuration UI" extension point that 
defines a set of "tabbed panes" that can be used to create/modify client 
specific launch configuration data. There will a generic UI supplied by 
the debugger to edit the launch configuration data that is 
applicable/generic to all launch configurations. For example, the debug UI 
will provide a tabbed pane for editing the "shared vs. local" property of 
a launch configuration. However, the Java debug UI will provide tabbed 
panes for editing VM and program arguments. This too is extensible. 

I am not sure that I understand your second question regarding "sharing". 
I think your question is, "how can one control if a launch config is 
shared or local by default?". If so, then yes, we could make this a 
preference by workspace or project. 

Darin 




Dave_Dykstal@xxxxxxx 
Sent by: platform-debug-dev-admin@xxxxxxxxxxx 
11/26/2001 01:59 PM 
Please respond to platform-debug-dev 
        
        To:        platform-debug-dev@xxxxxxxxxxx 
        cc: 
        Subject:        Re: [platform-debug-dev] Launch Configurations


Darin --

I noticed this was posted to both the JDT and debug mailing lists.  The 
proposal is very Java specific.  There may be projects in the future that 
have executable elements that should have launch configurations as well. 
Furthermore command syntax for actually doing the launches can change and 
the launches may be done locally or remotely.  Is there some way to 
accomodate these ideas in the scope of this proposal?  One could even 
imagine a project with multiple natures with launch configurations being 
built for different kinds of executable elements -- some Java, some not. 
This changes how the wizards that create configs could be constructed.

The shared config support is interesting.  There may be a notion of a 
project having to generate stuff to support a team that is separate from 
the launch idea.  It would be good if there were some standard query of a 
project or its natures that would influence the default for sharing these 
configurations.  Maybe this could be made a preference?  Alternatively, if 

this were a property of the project perhaps the new launch configuration 
wizard could be primed for this project with the appropriate defaults.

-- Dave
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev