Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?
Hi Doug,

I have recommended to people to do the fork, at least as a last resort. But the main people shipping products based on CDT seem to mostly be on Luna with plans to upgrade to Mars in the next 12 months. That means they are actually still another year away from being bitten by the CDI removal. Fortunately "some" of them simply plan to move to DSF!

Fortunately in this case of the ARM plug-ins, it is not relevant as these plugins are not actually using CDI, just some references to CDI launch configuration properties that are trivially removed.

I think the challenging change is this case is the API changes that are inherent with a major version change. In Liviu's case, on my quick pass the problem is the change of the constructor on GdbDebugServicesFactory (adding the ILaunchConfiguration parameter[1], extended here[2]). And of course this is only difficult because consumers of the ARM plug-ins want them updated for versions 8.x and 9.x of CDT. Simply updating the plug-ins for CDT 9.0 is trivial.



Jonah



On Monday, 23 May 2016, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:

I'm curious why no one has thought of forking the CDI plugins and maintaining them externally from Eclipse making them available to plugins developers such as these. My feeling is that this should work.

On May 23, 2016 12:34 PM, "John Cortell" <john.cortell@xxxxxxx> wrote:
This situation will not be a problem for KDS.

John

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Liviu Ionescu
> Sent: Monday, May 23, 2016 11:11 AM
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?
>
>
> > On 23 May 2016, at 16:03, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> >
> > ... It will be tricky to have one set of code support both CDT 8.x and
> > 9.x, so perhaps we could discuss the best way forward on that?
>
> hmmm... this doesn't sound very good, from what you say it looks like I need to
> maintain two separate versions of the plug-ins, and publish them in two separate
> update sites, which is not exactly my idea of fun.
>
> I am ready to change the code to avoid those deprecated classes, but we need to
> find alternate solutions available in CDT 8.6, since breaking compatibility with
> Luna will make lots of Freescale/NXP KDS users unable to update the plug-ins
> (KDS will be upgraded from Luna to Mars2 in early 2017).
>
> > The GNU
> > ARM Plug-ins are an important part of the Eclipse CDT ecosystem, and I
> > hope that we can get them supported in Neon/CDT 9.0.
>
> thank you for your nice words, Jonah, I appreciate your support.
>
> I don't know what is the best solution, but we need to find one that works both on
> 8.6 and 9.x, otherwise the GNU ARM plug-ins will remain stuck to the Mars 2
> version, maintaining two versions is not an option.
>
>
> regards,
>
> Liviu
>
> _______________________________________________
> 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