Bug 533332 - Make getEnclosingNode from SurroundWithAnalyzer API and move to jdt.core.manipulation
Summary: Make getEnclosingNode from SurroundWithAnalyzer API and move to jdt.core.mani...
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.8   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 4.9 M2   Edit
Assignee: Roland Grunberg CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2018-04-06 15:23 EDT by Roland Grunberg CLA
Modified: 2018-09-19 06:57 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Grunberg CLA 2018-04-06 15:23:39 EDT
eclipse.jdt.ls needs to use SurroundWithAnalyzer.getEnclosingNode(ASTNode) from jdt.ui.

In order to facilitate this move, some other classes will need to be moved into jdt.core.manipulation (eg. CodeAnalyzer, CommentAnalyzer, SelectionAnalyzer, etc.) as well, but they can remain internal for now as only some would need to be made API later on.
Comment 1 Eclipse Genie CLA 2018-04-06 16:20:34 EDT
New Gerrit change created: https://git.eclipse.org/r/120868
Comment 2 Dani Megert CLA 2018-04-07 08:53:23 EDT
(In reply to Roland Grunberg from comment #0)
> but they can remain internal for now as only some would need to be made API later on.

The inherited public and protected methods might bleed through if the API is not done correctly.
Comment 3 Roland Grunberg CLA 2018-04-11 13:43:54 EDT
(In reply to Dani Megert from comment #2)
> (In reply to Roland Grunberg from comment #0)
> > but they can remain internal for now as only some would need to be made API later on.
> 
> The inherited public and protected methods might bleed through if the API is
> not done correctly.

The API tooling should warn about such issues. In fact simply moving the classes from jdt.ui to jdt.core.manipuation and keeping them internal is still an improvement since it's the jdt.ui bundle that jdt.ls simply can't use.
Comment 4 Dani Megert CLA 2018-04-17 11:19:40 EDT
(In reply to Roland Grunberg from comment #3)
> (In reply to Dani Megert from comment #2)
> > (In reply to Roland Grunberg from comment #0)
> > > but they can remain internal for now as only some would need to be made API later on.
> > 
> > The inherited public and protected methods might bleed through if the API is
> > not done correctly.
> 
> The API tooling should warn about such issues.

Yes, it should - didn't check the patch.
Comment 6 Roland Grunberg CLA 2018-09-18 15:29:41 EDT
This appears to be in S4_9_0_M2. Can it be marked as such in target milestone and closed ?
Comment 7 Noopur Gupta CLA 2018-09-19 06:57:42 EDT
(In reply to Roland Grunberg from comment #6)
> This appears to be in S4_9_0_M2. Can it be marked as such in target
> milestone and closed ?

Yes, I will close it now. Going forward, we should close the bug with the correct target milestone when the change is released.