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

Alvaro, thanks for that feedback. I think that your suggestion is
exactly what I would do for a product based on Eclipse. As a product
you are not generally shipping for the plug-ins separately.

In your case are you shipping plug-ins, or a "complete" product? If
the former, are you shipping (planning to ship) two different sets of
plug-ins/update sites depending on which version of Eclipse the end
user want to install plug-ins into? How long do you plan to support
the two branches, e.g. does the CDT8.x targetting branch need to get
all the same new features as the CDT9.x branch?

I am surprised how long old versions of Eclipse and CDT are actively
being targetted for. Now that Neon is coming out, some people are
moving to Luna as their target platform if they need to upgrade at
all.

Thanks for sharing. I believe this is the kind of collaboration that
makes CDT such a great community to be part of.

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


On 3 June 2016 at 14:11, Alvaro Sanchez <alvsan09@xxxxxxxxx> wrote:
> 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
>
>
>
> _______________________________________________
> 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