Summary: | Bad package structure of org.eclipse.jdt.ui and org.eclipse.jdt.core.manipulation (?) | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Carsten Hammer <carsten.hammer> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | jjohnstn, kalyan_prasad, noopur_gupta, stephan.herrmann |
Version: | 4.20 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Carsten Hammer
2021-05-03 16:49:50 EDT
I share the notion that these split packages are problematic. The following query highlights (fairly) recent activity to move code from jdt.ui to jdt.core.manipulation for the benefit of jdt.ls: https://bugs.eclipse.org/bugs/buglist.cgi?classification=Eclipse%20Project&component=UI&list_id=20862119&product=JDT&query_format=advanced&short_desc=jdt.ls&short_desc_type=allwordssubstr As I watched that activity from the side lines I had the impression, that this move might depend on keeping classes within the same package for continued accessibility - but I don't have the details here. If the migration to jdt.core.manipulation is (mostly?) complete, it might be interesting to analyze the situation achieved: How many classes in jdt.core.manipulation are (still) accessed by jdt.ui by way of the same-package privilege? As for making some API public, I believe this must be decided in small increments, because each new API creates a new liability during maintenance. So if you have specific requests, you may want to file separate bugs - perhaps start with the easiest example as a pilot :) Since moving types to a non-internal package creates incompatibilities among the jdt family of bundles, such activity should probably happen during some milestone 1, I guess. |