Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Allow new C/C++ project wizard extension

I posted a new patch that uses a base class rather than introducing a new interface. Please take a look and let me know if that is more acceptable.

Greg

On Oct 23, 2009, at 4:24 AM, Schorn, Markus wrote:

Greg,
your patch is still an API change. Please enable the API tooling and you'll get the according error
messages. If you want support for that in a maintenance branch you can only do that via an internal
class or interface. A public solution can go into CDT 6.1. Just adding a comment that the interface
is provisional is not helpful because the API tooling will not be able to deal with it. For example, what
would be the correct since tag for such an interface? Depending on whether your api-baseline is
CDT 6.0.0 or CDT 6.0.2 the tooling would require a different since tag.
 
Also, please do not introduce public interfaces without @noimplement tags (unless absolutely
necessary), they cannot be evolved without a breaking API change.
 
Markus.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Watson
Sent: Thursday, October 22, 2009 11:17 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Allow new C/C++ project wizard extension
Importance: Low

Doug,

As usual, you're right :-). I've uploaded a new patch that doesn't change the existing hierarchy, but still allows the CDTCommonProjectWizard to be replaced.

Greg

On Oct 22, 2009, at 4:24 PM, Doug Schaefer wrote:

With this change, what happens to 3rd party classes that extend CDTCommonProjectWizard given that you've changed it's interface inheritance hierarchy? I'm not a Java bytecode expert so I don't know. But I have to ask the question.

Again, the requirement is not to break anyone. If you don't I don't consider this an API change.

:D.


On Thu, Oct 22, 2009 at 3:16 PM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:

On Oct 22, 2009, at 3:04 PM, Doug Schaefer wrote:

On Thu, Oct 22, 2009 at 2:03 PM, Mike Kucera <mkucera@xxxxxxxxxx> wrote:

In PTP we have created a "Remote C/C++ Project" which allows you to create a CDT project where the files are stored in a remote location and accessed via EFS. We have also created our own version of the CDT new project wizard which has been redesigned to work better for creating remote projects. But in order to get this to work we need to be able to swap out the default CDT wizard with our own. This requires a small API change. Greg has uploaded a patch to bug 293079 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=293079).


Does this mean if you have PTP installed your new C++ project wizard will be different?
 

Now, the issue is that PTP is based on CDT 6, so does anyone have an objection if I apply the patch to the 6.0 branch?

Yes, CDT 6 is API frozen. I've already squashed a number of requests from Wind Riverites to change APIs. We need to follow API guidelines to make sure adopters using those APIs can install a new CDT 6.0.x without having to recompile their plug-ins.

This change wouldn't require any recompilation of third party plugins. Why couldn't this be an experimental/internal API that we use at our own risk, at least until 7.0? The current new project wizard design makes it impossible to extend the wizard, so this would ultimately be beneficial IMHO.

Greg

_______________________________________________
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

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top