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.
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
|