Re: Run/Debug profiles

What will be the next steps in this area ?

It looks like the team has agreed on simplifying the run/debug profiles 
area, so can the UI spec be changed accordingly ? And can this be 
factored into the plan ?

FYI - I created an issuezilla task: 
http://www.netbeans.org/issues/show_bug.cgi?id=33325

Petr

cL wrote:

> i'm all for this simplification! the only point i would want to focus on 
> is the dual choice of a default for debugging and a default for running. 
> a further simplification would be to just set a profile active for 
> running and/or debugging as it seems to me that the most common case has 
> the user working on one profile and running/debugging with that until 
> they move on to the next task.  i worry that setting different default 
> profiles for run and debug adds complexity to the ui and forces the user 
> to remember more little details about the system they are working with 
> (as opposed to the code they are working on).
> 
> i think two active profiles will invite the situation where the user 
> changes the active run profile, sees a problem, hits debug; goes 'huh?' 
> because the debugger spits out something they didn't expect; goes 'doh!' 
> because they need to switch the debug profile too; changes the profile 
> for debug as well and continues on their merry way. conversely, user is 
> debugging, fixes bugs, hits run; goes 'huh?' because it runs something 
> unexpected; goes 'doh!' because they need to change the run profile; 
> changes the run profile and continues on their merry way.
> 
> on the other hand, user wants to debug in one profile, so they set the 
> profile and debug. later they want to run in a different profile so they 
> set the profile and do so. no confusion bcs the profile is always in an 
> easily remembered state  -even though in some cases it means they need 
> to change profiles with some increased frequency it avoids the 'huh? 
> doh!' cycle.
> 
> cL
> 
> Petr Jiricka wrote:
> 
>>
>> Svata Dedic wrote:
>>
>>> Evan Adams wrote:
>>>
>>>>
>>>> I've heard an argument that in some scenarios a debugged
>>>> version of a jar file should be used.  The Debug profile
>>>> would allow this user to specify a different classpath.
>>>> Personally, I don't find this scenario very compelling
>>>> as I don't think it occurs very often.
>>>>
>>> If the project uses libraries, which have been compiled with line 
>>> number information, then you are right.
>>>
>>> However I don't think that the patterns  of how a project is 
>>> created/managed will remain unchanged from what they are now when 
>>> build configurations are used into the IDE. You may consider looking 
>>> and MSVC++, which support Debug/Release configuration: Release is 
>>> typically set up to build with debug info, against debug libs (which 
>>> are built with debug info) etc. Release config builds without all 
>>> that and is typically optimized.
>>> Try to debug into the Release version of a library :-)
>>
>>
>>
>>
>> I don't have a strong opinion on this, but either way, the design I 
>> proposed (and which is hopefully getting people's agreement) 
>> accomodates this scenario as well. The user can manually set up two 
>> Run/Debug profile instances, and then use one of them exclusively for 
>> running and the other for debugging: the easy stuff is easy, and the 
>> hard/unusual stuff is still possible.
>>
>> The one question to think about is whether by default, new project 
>> should be configured with two separate profiles, as it is now (they 
>> would only be in the same group, not in two), or whether one profile 
>> would be sufficient. For WebApps, we think that one should definitely 
>> be sufficient. For plain Java project, I would think the same, however 
>> it's not up to me to decide.
>>
>>
>> Speaking of the proposal in general, I would also like to know the 
>> opinions of the other people involved: Chris, Tomas ?
>>
>> Thanks
>> Petr
>>
>>
>>>
>>> -Svata
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>