Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Porting issue from Luna to Neon

Hi, 
We have a similar situation with our plugins extending CDT, 
in our team discussions we considered using a similar approach to Jonah's suggestion, 
  This option would work but will leave your code base not clean, and something you will probably have to keep in mind in the future,
So we decided to branch out our extensions instead, and separate our builds, 
the old interfaces and its branch will soon be obsolete and your code base will remain clean.

Something to consider.
/Alvaro

On Fri, Jun 3, 2016 at 4:27 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi Velimir,

When I was working with Liviu to solve similar API issues with the
GNUARM plug-ins I did go down the thought exercise of multiple
plug-ins. I think it should be possible by tightly specifying your
version ranges, however I came to the conclusion that it was a harder
solution than the slight refactoring needed. In my opinion it is
harder because then you are maintaining two source bases for that
plug-in.

Jonah


~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 3 June 2016 at 08:46, Velimir Topaloski
<Velimir.Topaloski@xxxxxxxxxxxx> wrote:
> Hi Johan,
>
>
>
> Thanks for your prompt reply.
>
>
>
> I was also thinking somewhere along those lines and will certainly try out
> your suggestion.
>
>
>
> To be honest, I was hoping for some mechanism in Eclipse that allows me, at
> runtime, use different
>
> versions of classes depending on which version of Eclipse is currently
> running…
>
>
>
> On the other hand, I am not sure, if such a mechanism creates maintenance
> problems down the road…
>
>
>
> The plugin is a part of a commercial product, therefore its source code is
> not publicly available.
>
>
>
> Best Regards,
>
> Velimir
>
>
>
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Jonah Graham
> Sent: Friday, June 03, 2016 09:28
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-dev] Porting issue from Luna to Neon
>
>
>
> Hi Velimir,
>
>
>
> Here is an idea of how to solve it, I haven't tried it, but it shoud at
> least move to the next step.
>
>
>
> In this case you should duplicate createMIBreakInsert function, one with tid
> as int, one as string. Then remove the @Override (with a suitable comment
> ;-) so you don't have compile errors when you compile. When you run against
> Neon one of the methods will be called, but with Luna it will be the other
> one.
>
>
>
> Then, do you use standard MIBreakInsert? If so, copy the new version from
> Neon into your code base and add the Luna constructor to it. If
> MIBreakInsert is already your own, then I think it is more straightforward.
>
>
>
> Is your code OSS on the web somewhere?
>
>
>
> HTH and let us know,
>
> Jonah
>
>
>
>
> On Friday, 3 June 2016, Velimir Topaloski <Velimir.Topaloski@xxxxxxxxxxxx>
> wrote:
>
> Hi Guys,
>
>
>
> I have the following problem related to Bug 489777…
>
>
>
> I have an Eclipse Plugin for Eclipse Luna that extends CommandFactory_6_8
> class and overrides createMIBreakInsert() functions.
>
>
>
> class MyCommandFactory extends CommandFactory_6_8 {
>
>     @Override
>
>     public ICommand<MIBreakInsertInfo>
> createMIBreakInsert(IBreakpointsTargetDMContext ctx, boolean isTemporary,
>
>                                                            boolean
> isHardware, String condition, int ignoreCount,
>
>                                                            String location,
> int tid, boolean disabled, boolean isTracepoint) {
>
>
>
>         /*
>
>          *  Here is some custom code
>
>          */
>
>         return new MIBreakInsert(ctx, isTemporary, isHardware, condition,
> ignoreCount, location, tid, disabled, isTracepoint, true);
>
>     }
>
> }
>
>
>
> As you already might know, the “thread id” parameter in
> createMIBreakInsert() has changed from “int” to “String”.
>
>
>
> Currently I am trying to port the plugin to Eclipse Neon and still keeping
> the Eclipse Luna support,
>
> but the change introduced to the createMIBreakInsert() functions is standing
> in the way.
>
>
>
> I am not really sure how, if possible, to solve this problem.
>
>
>
> I would really appreciate if you could give me some pointers or ideas how to
> circumvent the issue…
>
>
>
> Thanks in advance,
>
> Velimir
>
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top