[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
