FW: [cdt-dev] Minor API Change Requests for TM RemoteCDT Integrat ion

[Doug Schaefer <DSchaefer@xxxxxxx>]

I have no problem with making AbstractCDebuggerTab API. I'm not sure how it
would break debugger integrations, unless they were using the internal
interface...

It is CDT 4.0, people will expect some breakage, and won't mind if it is
easy to fix.

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com


> -----Original Message-----
> From: Mikhail Khodjaiants [mailto:Mikhail.Khodjaiants@xxxxxxx]
> Sent: Thursday, March 29, 2007 6:53 AM
> To: CDT General developers list.
> Cc: Doug Schaefer
> Subject: RE: [cdt-dev] Minor API Change Requests for TM RemoteCDT
> Integration
> 
> Hi Martin,
> 
> I don't think 178832 would be a problem, I'll do it tonight.
> Regarding 178831, I agree that it is an inconsistency and I am ready to
> make it public, but I have been waiting for a reaction. I am sure it
> will break some products.
> Doug, what do you think?
> 
> Regards,
> Mikhail
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Oberhuber, Martin
> Sent: 29 March 2007 11:33
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Minor API Change Requests for TM RemoteCDT
> Integration
> 
> Hello Mikhail,
> 
> thanks for your answer.
> 
> The RSE remotecdt plugin can be viewed at
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.rse/examples/org
> .eclipse.rse.remotecdt/?root=DSDP_Project
> 
> Or you check it out into your workspace:
>    Repository   :pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/dsdp
>    Project      org.eclipse.tm.rse/examples/org.eclipse.rse.remotecdt
> 
> I understand your concerns that you don't want to put work into
> something that looks pretty broken anyways. Especially taking into
> account that with CDT, lots of people use classes from "internal"
> and moving such a class from internal into API is a breaking change for
> them (while it would just continue working if the change is not made).
> 
> Still, I'd like to see these two resolved:
> 
> > API inconsistency: AbstractCDebuggerTab
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=178831
> 
> because it is an inconsistency
> 
> > Request CLaunchConfigurationTab.setDialogShell()
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=178832
> 
> because this is a very simple non-breaking change which even has a patch
> attached.
> 
> Thanks,
> --
> Martin Oberhuber
> Wind River Systems, Inc.
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> > Sent: Thursday, March 22, 2007 7:49 PM
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] Minor API Change Requests for TM RemoteCDT
> > Integration
> >
> > Hi Martin,
> >
> > As you can see the division to the public and internal in the
> > launcher-related classes is not particularly good. I think at the
> > beginning most of the UI component were intended to be internal, but
> > we haven't followed this principle and now it's a mess. The internal
> > AbstractCDebuggerTab and public CDebuggerTab is a good example.
> > Moreover in some of my remote launch configurations I am subclassing
> > the non-public classes, because I have been too lazy to write my own
> > UI from scratch. I believe that most of the CDT extensions do the
> > same.
> > At the same time I would prefer to minimize the number of public UI
> > components. It is not easy to support it, for example, the Eclipse
> > Debug team is very reluctant to do it. Maybe this is the right time to
> 
> > reorganize the launch plugin structure instead of opening more and
> > more classes to public.
> > Do you have a description of your launch configuration components? It
> > would be helpful to understand what are you trying to do and come up
> > with a common solution.
> >
> > Regards,
> > Mikhail
> >
> > PS It would be nice to hear the opinion of the original owner of the
> > launch plugin, Dave Inglis.
> >
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Oberhuber, Martin
> > Sent: 22 March 2007 17:24
> > To: CDT General developers list.
> > Subject: [cdt-dev] Minor API Change Requests for TM RemoteCDT
> > Integration
> >
> > Dear CDT Committers,
> >
> > as you might be aware, the TM project provides a CDT integration,
> > which allows remote debugging through gdb / gdbserver, including
> > automatic upload and remote launching of gdbserver itself.
> >
> > Our integration currently needs to use CDT "internal"
> > classes or methods in three cases. According to the Europa Coordinate
> > Release planning meeting [1], I thus request API changes in the CDT in
> 
> > order to allow our plugin work through official channels.
> >
> > I think that all three requests are really small and reasonable, so I
> > hope this can be done.
> >
> > API inconsistency: AbstractCDebuggerTab
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=178831
> >
> > Request CLaunchConfigurationTab.setDialogShell()
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=178832
> >
> > GDBDebuggerPage should be API
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=178835
> >
> >
> > Once committers agree that this is something you want, the
> > implementation should be doable within minutes since it is just a
> > simple "move" refactoring or applying my patch.
> >
> > [1] For reference, see section "Using Non-APIs" in
> > http://www.eclipse.org/org/councils/20070123PCMinutes.php
> >
> >
> > Thanks,
> > --
> > Martin Oberhuber
> > Wind River Systems, Inc.
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> > --
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose
> > the contents to any other person, use it for any purpose, or store or
> > copy the information in any medium.  Thank you.
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev