Community
Participate
Working Groups
I'm not completely sure that I do not missunderstand something but I think to have identical package names in two different bundles is not a good thing. We have the package org.eclipse.jdt.internal.coreext in both bundles org.eclipse.jdt.ui org.eclipse.jdt.core.manipulation How is a third bundle to depend on both of them supposed to be setup (e.g to create some junit tests)? Isn't the classloader of one bundle unable to serve all classes of the other bundle this way? Doesn't this cause issues? I've already seen problems but could be I overlook an important point here. Besides there are x-friends declarations in org.eclipse.jdt.core.manipulation to allow access from org.eclipse.jdt.ui and some dedicated test packages. But it is not possible to create my own test bundle this way, imho. Maybe if I name the bundle identical to the existing test bundle. But that seems to be not a clean design. In a number of cases I wonder why the classes are in an "internal" package that is not supposed to be visible outside. I really like this encapsulation but wonder if the choice what is visible and what is not is always right. Just think of org.eclipse.jdt.internal.ui.preferences.cleanup.CleanUpModifyDialog.FALSE_TRUE Aren't such constants something that should be reused in third party plugins and therefore it should be visible in a depending bundle? This one is x-internal:=true. Does it make sense to create another "Jdt ui examples" project to show how to create some independent extensions, junit tests and so on?
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.
