[
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
