Convert CEditor to ICModelEditor
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have an eclipse plugin which extends some of the features provided by CDT.
The problem is that the plugin is supposed to support multiple CDT versions.
One of the plugin classes extends the SelectionParseAction class from CDT:
class CustomSelectionParseAction extends SelectionParseAction {
public CustomSelectionParseAction(CEditor editor) {
super(editor);
}
}
The constructor signature of SelectionParseAction changed from CDT 8.* to CDT 9.*(diff link).
public SelectionParseAction(ICEditor editor)
becamepublic SelectionParseAction(ICModelBasedEditor editor)
Since the input for my CustomSelectionParseAction will remain an CEditor object, how could I support both CDT class constructors?
java eclipse-plugin eclipse-rcp eclipse-cdt eclipse-pde
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
|
show 1 more comment
I have an eclipse plugin which extends some of the features provided by CDT.
The problem is that the plugin is supposed to support multiple CDT versions.
One of the plugin classes extends the SelectionParseAction class from CDT:
class CustomSelectionParseAction extends SelectionParseAction {
public CustomSelectionParseAction(CEditor editor) {
super(editor);
}
}
The constructor signature of SelectionParseAction changed from CDT 8.* to CDT 9.*(diff link).
public SelectionParseAction(ICEditor editor)
becamepublic SelectionParseAction(ICModelBasedEditor editor)
Since the input for my CustomSelectionParseAction will remain an CEditor object, how could I support both CDT class constructors?
java eclipse-plugin eclipse-rcp eclipse-cdt eclipse-pde
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
The reason Eclipse CDT felt free to change the signature was because this is an internal class. You are violating the Eclipse API Rules of Engagement by extending such classes.
– greg-449
Nov 22 '18 at 11:22
@greg-449 I am just the unlucky maintainer of the plugin. I don't blame the CDT changes and I am totally aware that the extended class isnot APIand theaccess is discouraged. However, I was wondering if I can find a solution to patch this situation.
– Garry White
Nov 22 '18 at 11:29
CEditorimplementsICModelBasedEditor, so shouldn't it just work?
– HighCommander4
Nov 22 '18 at 18:02
It doesn't because at run time it tries to call the constructorsuper(CEditor)which doesn't exist anymore, thereforejava.lang.NoSuchMethodError. I am thinking to copy in the plugin the old implementation ofSelectionParseActionand just use that one until we get rid of thenon-API code.
– Garry White
Nov 23 '18 at 7:49
1
I see... the change is source-compatible for your plugin, but not binary-compatible. Can you distribute different builds of your plugin for CDT 8.x and CDT 9.x?
– HighCommander4
Nov 24 '18 at 7:16
|
show 1 more comment
I have an eclipse plugin which extends some of the features provided by CDT.
The problem is that the plugin is supposed to support multiple CDT versions.
One of the plugin classes extends the SelectionParseAction class from CDT:
class CustomSelectionParseAction extends SelectionParseAction {
public CustomSelectionParseAction(CEditor editor) {
super(editor);
}
}
The constructor signature of SelectionParseAction changed from CDT 8.* to CDT 9.*(diff link).
public SelectionParseAction(ICEditor editor)
becamepublic SelectionParseAction(ICModelBasedEditor editor)
Since the input for my CustomSelectionParseAction will remain an CEditor object, how could I support both CDT class constructors?
java eclipse-plugin eclipse-rcp eclipse-cdt eclipse-pde
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
I have an eclipse plugin which extends some of the features provided by CDT.
The problem is that the plugin is supposed to support multiple CDT versions.
One of the plugin classes extends the SelectionParseAction class from CDT:
class CustomSelectionParseAction extends SelectionParseAction {
public CustomSelectionParseAction(CEditor editor) {
super(editor);
}
}
The constructor signature of SelectionParseAction changed from CDT 8.* to CDT 9.*(diff link).
public SelectionParseAction(ICEditor editor)
becamepublic SelectionParseAction(ICModelBasedEditor editor)
Since the input for my CustomSelectionParseAction will remain an CEditor object, how could I support both CDT class constructors?
java eclipse-plugin eclipse-rcp eclipse-cdt eclipse-pde
java eclipse-plugin eclipse-rcp eclipse-cdt eclipse-pde
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
asked Nov 22 '18 at 11:20
Garry WhiteGarry White
647
647
The reason Eclipse CDT felt free to change the signature was because this is an internal class. You are violating the Eclipse API Rules of Engagement by extending such classes.
– greg-449
Nov 22 '18 at 11:22
@greg-449 I am just the unlucky maintainer of the plugin. I don't blame the CDT changes and I am totally aware that the extended class isnot APIand theaccess is discouraged. However, I was wondering if I can find a solution to patch this situation.
– Garry White
Nov 22 '18 at 11:29
CEditorimplementsICModelBasedEditor, so shouldn't it just work?
– HighCommander4
Nov 22 '18 at 18:02
It doesn't because at run time it tries to call the constructorsuper(CEditor)which doesn't exist anymore, thereforejava.lang.NoSuchMethodError. I am thinking to copy in the plugin the old implementation ofSelectionParseActionand just use that one until we get rid of thenon-API code.
– Garry White
Nov 23 '18 at 7:49
1
I see... the change is source-compatible for your plugin, but not binary-compatible. Can you distribute different builds of your plugin for CDT 8.x and CDT 9.x?
– HighCommander4
Nov 24 '18 at 7:16
|
show 1 more comment
The reason Eclipse CDT felt free to change the signature was because this is an internal class. You are violating the Eclipse API Rules of Engagement by extending such classes.
– greg-449
Nov 22 '18 at 11:22
@greg-449 I am just the unlucky maintainer of the plugin. I don't blame the CDT changes and I am totally aware that the extended class isnot APIand theaccess is discouraged. However, I was wondering if I can find a solution to patch this situation.
– Garry White
Nov 22 '18 at 11:29
CEditorimplementsICModelBasedEditor, so shouldn't it just work?
– HighCommander4
Nov 22 '18 at 18:02
It doesn't because at run time it tries to call the constructorsuper(CEditor)which doesn't exist anymore, thereforejava.lang.NoSuchMethodError. I am thinking to copy in the plugin the old implementation ofSelectionParseActionand just use that one until we get rid of thenon-API code.
– Garry White
Nov 23 '18 at 7:49
1
I see... the change is source-compatible for your plugin, but not binary-compatible. Can you distribute different builds of your plugin for CDT 8.x and CDT 9.x?
– HighCommander4
Nov 24 '18 at 7:16
The reason Eclipse CDT felt free to change the signature was because this is an internal class. You are violating the Eclipse API Rules of Engagement by extending such classes.
– greg-449
Nov 22 '18 at 11:22
The reason Eclipse CDT felt free to change the signature was because this is an internal class. You are violating the Eclipse API Rules of Engagement by extending such classes.
– greg-449
Nov 22 '18 at 11:22
@greg-449 I am just the unlucky maintainer of the plugin. I don't blame the CDT changes and I am totally aware that the extended class is
not API and the access is discouraged. However, I was wondering if I can find a solution to patch this situation.– Garry White
Nov 22 '18 at 11:29
@greg-449 I am just the unlucky maintainer of the plugin. I don't blame the CDT changes and I am totally aware that the extended class is
not API and the access is discouraged. However, I was wondering if I can find a solution to patch this situation.– Garry White
Nov 22 '18 at 11:29
CEditor implements ICModelBasedEditor, so shouldn't it just work?– HighCommander4
Nov 22 '18 at 18:02
CEditor implements ICModelBasedEditor, so shouldn't it just work?– HighCommander4
Nov 22 '18 at 18:02
It doesn't because at run time it tries to call the constructor
super(CEditor) which doesn't exist anymore, therefore java.lang.NoSuchMethodError. I am thinking to copy in the plugin the old implementation of SelectionParseAction and just use that one until we get rid of the non-API code.– Garry White
Nov 23 '18 at 7:49
It doesn't because at run time it tries to call the constructor
super(CEditor) which doesn't exist anymore, therefore java.lang.NoSuchMethodError. I am thinking to copy in the plugin the old implementation of SelectionParseAction and just use that one until we get rid of the non-API code.– Garry White
Nov 23 '18 at 7:49
1
1
I see... the change is source-compatible for your plugin, but not binary-compatible. Can you distribute different builds of your plugin for CDT 8.x and CDT 9.x?
– HighCommander4
Nov 24 '18 at 7:16
I see... the change is source-compatible for your plugin, but not binary-compatible. Can you distribute different builds of your plugin for CDT 8.x and CDT 9.x?
– HighCommander4
Nov 24 '18 at 7:16
|
show 1 more comment
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53429824%2fconvert-ceditor-to-icmodeleditor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53429824%2fconvert-ceditor-to-icmodeleditor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The reason Eclipse CDT felt free to change the signature was because this is an internal class. You are violating the Eclipse API Rules of Engagement by extending such classes.
– greg-449
Nov 22 '18 at 11:22
@greg-449 I am just the unlucky maintainer of the plugin. I don't blame the CDT changes and I am totally aware that the extended class is
not APIand theaccess is discouraged. However, I was wondering if I can find a solution to patch this situation.– Garry White
Nov 22 '18 at 11:29
CEditorimplementsICModelBasedEditor, so shouldn't it just work?– HighCommander4
Nov 22 '18 at 18:02
It doesn't because at run time it tries to call the constructor
super(CEditor)which doesn't exist anymore, thereforejava.lang.NoSuchMethodError. I am thinking to copy in the plugin the old implementation ofSelectionParseActionand just use that one until we get rid of thenon-API code.– Garry White
Nov 23 '18 at 7:49
1
I see... the change is source-compatible for your plugin, but not binary-compatible. Can you distribute different builds of your plugin for CDT 8.x and CDT 9.x?
– HighCommander4
Nov 24 '18 at 7:16