[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] [DSF] FinalLaunchSequence extensibility

Right. We should make use of the Eclipse extension point mechanism to
allow contributions to the steps library.
And we can include the steps from the ServicesLaunchSequence in the
library too.

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mikhail Khodjaiants
Sent: July 8, 2010 3:35 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility

On 08/07/2010 2:54 PM, Marc Khouzam wrote:
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx
>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
>> Sent: Thursday, July 08, 2010 2:27 PM
>> To: cdt-dev@xxxxxxxxxxx
>> Subject: Re: [cdt-dev] [DSF] FinalLaunchSequence extensibility
>>
>> On 08/07/2010 2:04 PM, Marc Khouzam wrote:
>>      
>>> That is interesting.  It's like the subSequence solution, with each 
>>> subSequence being a single step.  How would you define the step ids?
>>>
>>>        
>> Yes, that's correct. See the Andy Jin's comment regarding
granularity.
>> I was thinking of the traditional Eclipse style strings:
>> <plugin_id>.steps.gdbinit, for instance.
>>      
> Thinking about it some more, isn't this very much like Vladimir's 
> early
> suggestion:
>    
>> - Add protected members for each step of FinalLaunchSequence, e.g.:
>>
>> 	protected Step getTrackerStep = new Step() { .... } ;
>>
>> - Add factory methods, e.g.:
>>
>>      protected Step getTrackerStep() { .... }
>>      
It is similar. But the difference is to have a steps library outside of
FinalLaunchSequence.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev