Community
Participate
Working Groups
Created attachment 280270 [details] Contains a project with an invalid product because of this bug With fix 549229 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=549229) the dependency "org.eclipse.jface.text" was added to "org.eclipse.ui.workbench". This leads to the problem that the feature "org.eclipse.rcp" also has a dependency to the plugin "org.eclipse.jface.text" (because "org.eclipse.ui.workbench" is included. Feature based products using org.eclipse.rcp (without platform) are now missing the 2 plugins: - org.eclipse.jface.text - org.eclipse.text This problem can be reproduced by validating the product file within the attachement. This problem may be solved by including the missing plugins in "org.eclipse.rcp". See also https://github.com/aposin/MergeProcessor/pull/26
(In reply to Stefan Weiser from comment #0) > With fix 549229 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=549229) the > dependency "org.eclipse.jface.text" was added to "org.eclipse.ui.workbench". Wrong bug? I don't see related changes in bug 549229.
Sorry, wrong bug referenced. This is the correct one. https://bugs.eclipse.org/bugs/show_bug.cgi?id=546251
Matthias, please check this one.
New Gerrit change created: https://git.eclipse.org/r/151210
(In reply to Andrey Loskutov from comment #3) > Matthias, please check this one. See my gerrit. Can you please review and give your ok for that change?
(In reply to Matthias Becker from comment #5) > (In reply to Andrey Loskutov from comment #3) > > Matthias, please check this one. > > See my gerrit. Can you please review and give your ok for that change? I'm not experienced with feature / product definitions, but for me it looks like the org.eclipse.jface.text / org.eclipse.text should go to the org.eclipse.e4.rcp feature, that already contains org.eclipse.jface and org.eclipse.jface.databinding. But I would ask someone else who has an idea why do we have two rcp features one including another. @All on CC: could you please check this bug / patch https://git.eclipse.org/r/#/c/151210/ ?
As e4 does not depend on org.eclipse.ui, adding the text bundles to the e4 feature would be wrong.
Preferred would be a solution without dependency from UI to text. Looks like this dependency was introduced to use a bold style provider. Can this be implemented with the normal JFace provider or can the provider be moved to JFace? RCP should not depend on text
New Gerrit change created: https://git.eclipse.org/r/151222
New Gerrit change created: https://git.eclipse.org/r/151223
(In reply to Lars Vogel from comment #8) > Preferred would be a solution without dependency from UI to text. Looks like > this dependency was introduced to use a bold style provider. Can this be > implemented with the normal JFace provider or can the provider be moved to > JFace? > > RCP should not depend on text See my next to gerrits. Are they okay?
(In reply to Matthias Becker from comment #11) > (In reply to Lars Vogel from comment #8) > > Preferred would be a solution without dependency from UI to text. Looks like > > this dependency was introduced to use a bold style provider. Can this be > > implemented with the normal JFace provider or can the provider be moved to > > JFace? > > > > RCP should not depend on text > > See my next to gerrits. Are they okay? Thanks. They look good to me.
(In reply to Lars Vogel from comment #12) > (In reply to Matthias Becker from comment #11) > > (In reply to Lars Vogel from comment #8) > > > Preferred would be a solution without dependency from UI to text. Looks like > > > this dependency was introduced to use a bold style provider. Can this be > > > implemented with the normal JFace provider or can the provider be moved to > > > JFace? > > > > > > RCP should not depend on text > > > > See my next to gerrits. Are they okay? > > Thanks. They look good to me. Is the deprecation-patch also okay? For: {@link org.eclipse.jface.viewer.BoldStylerProvider )} I get the warning: "Javadoc: org.eclipse.jface.viewer cannot be resolved to a type" Why?
Gerrit change https://git.eclipse.org/r/151222 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ea06254ca16618268c06775f36b675f4f761daef
(In reply to Matthias Becker from comment #13) > Is the deprecation-patch also okay? For: > {@link org.eclipse.jface.viewer.BoldStylerProvider )} > I get the warning: > "Javadoc: org.eclipse.jface.viewer cannot be resolved to a type" > > Why?
Gerrit change https://git.eclipse.org/r/151223 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=df9dfa9ffc21130c92f18bfe7b9a268121780c36
Thanks, Matthias.
BoldStylerProvider is now deprecated, so there is any clean alternative to ICompletionProposalExtension7?
(In reply to Dawid Pakula from comment #18) > BoldStylerProvider is now deprecated, so there is any clean alternative to > ICompletionProposalExtension7? That deprecation was not correct - at least not without providing a valid alternative to org.eclipse.jface.text.contentassist.ICompletionProposalExtension7.getStyledDisplayString(IDocument, int, BoldStylerProvider)
(In reply to Dani Megert from comment #19) > (In reply to Dawid Pakula from comment #18) > > BoldStylerProvider is now deprecated, so there is any clean alternative to > > ICompletionProposalExtension7? > That deprecation was not correct - at least not without providing a valid > alternative to > org.eclipse.jface.text.contentassist.ICompletionProposalExtension7. > getStyledDisplayString(IDocument, int, BoldStylerProvider) So what need to be done here?
(In reply to Matthias Becker from comment #20) > (In reply to Dani Megert from comment #19) > > (In reply to Dawid Pakula from comment #18) > > > BoldStylerProvider is now deprecated, so there is any clean alternative to > > > ICompletionProposalExtension7? > > That deprecation was not correct - at least not without providing a valid > > alternative to > > org.eclipse.jface.text.contentassist.ICompletionProposalExtension7. > > getStyledDisplayString(IDocument, int, BoldStylerProvider) > > So what need to be done here? Either remove the deprecation or provide an alternative.
Ping!
New Gerrit change created: https://git.eclipse.org/r/162880
(In reply to Dani Megert from comment #22) > Ping! see my revert
New Gerrit change created: https://git.eclipse.org/r/162976
Gerrit change https://git.eclipse.org/r/162880 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=06fb93d52c43fe3a4334024b5a2ca80973dbaab0
(In reply to Eclipse Genie from comment #26) > Gerrit change https://git.eclipse.org/r/162880 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > ?id=06fb93d52c43fe3a4334024b5a2ca80973dbaab0 I see API error after this commit. on org.eclipse.jface.text: The minor version should be incremented in version 3.16.300, since new APIs have been added since version 3.16.200
(In reply to Andrey Loskutov from comment #27) > (In reply to Eclipse Genie from comment #26) > > Gerrit change https://git.eclipse.org/r/162880 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/ > > ?id=06fb93d52c43fe3a4334024b5a2ca80973dbaab0 > > I see API error after this commit. on org.eclipse.jface.text: > > The minor version should be incremented in version 3.16.300, since new APIs > have been added since version 3.16.200 I already asked this in the gerrit: https://git.eclipse.org/r/#/c/162880/ I don't know why Dani has merged it.
It doesn't need version increment as it's removal of deprecation. I'll add api filter.
(In reply to Alexander Kurtakov from comment #29) > It doesn't need version increment as it's removal of deprecation. I'll add > api filter. Thank you.
New Gerrit change created: https://git.eclipse.org/r/163579
Gerrit change https://git.eclipse.org/r/163579 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=211edf5b44906abd0499473dce60f359ee030729
Unless someone has some other pending issue I'll resolve this one tomorrow.
(In reply to Alexander Kurtakov from comment #33) > Unless someone has some other pending issue I'll resolve this one tomorrow. okay for me