Community
Participate
Working Groups
We are using internal jdt calls to perform some of our operations. In order to bring up the package selection dialog we needed to use PackageSelectionDialog. We couldn't find public API to replace this usage. JavaUI.createPackageDialog(..) does not provide any way to use the workspace scope for the dialog which is what we need in our usecase. This is blocking our effort to remove access to JDT internal source.
Yes we should add new API JavaUI.createPackageDialog(Shell parent, IPackageFragmentRoot root, int style, String filter) and use the PackageSelectionDialog for this and also for the other API methods.
Would requiring an IPackageFragmentRoot argument still allow us to create the dialog with Workspace scope (i.e. dialog shows all packages in all projects in the workspace)?
Oops, sorry, what I wrote makes no sense: It would be something like public static SelectionDialog createPackageDialog(Shell parent, IRunnableContext context, IJavaSearchScope scope, int style, boolean multipleSelection, String filter) This API would use the PackageSelectionDialog. If possible also the other API's createPackageDialog(...IJavaProject...) should use the PackageSelectionDialog.
Created attachment 28515 [details] proposed fix Adds public static SelectionDialog createPackageDialog(Shell parent, IRunnableContext context, IJavaSearchScope scope, int flags, boolean multipleSelection, String filter) to JavaUI
I think the patch neds some more work. PackageSelectionDialog is internal, so the constants there need to be made public. Note that we don't need to make them all public, verify and decide if they make sense to be public API. Also have a look on how to change the existing API createPackageDialog(...IJavaProject...) to use the PackageSelectionDialog.
I've tried to change the existing code to use the new PackageSelectionDialog but the problem is, that the search for packages does not report any empty packages, wheras the old implementation does show empty packages. see MatchLocator#locatePackageDeclarations : IPackageFragment pkg = (IPackageFragment) pkgs[k]; IJavaElement[] children= pkg.getChildren(); if (children.length > 0 && ...) { ... report match ... } I don't know why search does not report empty pkgs, maybe we should file a pr against search?
Created attachment 29766 [details] proposed fix Create a PackageSelectionDialog with the same options as JDT/UI uses: REMOVE_DUPLICATES and SHOW_PARENTS and HIDE_DEFAULT_PACKAGE
Created attachment 29767 [details] test
It seems they made that on purpose. I suggest to add code in PackageSelectionDialog. I tried something, but didn't test. See attachment. In your patch, it seems to me that the null check on 'filter' is either too much or the spec should mention that 'null' is a valid option.
Created attachment 29769 [details] example how to add the default package
I see your point but the problem is that empty packages aren't shown. Your patch shows only the default package and only if there are only empty packages in the project. Let us assum we use the API in the new class wizard (which we should IMHO) and having following use case: - create new project - create new package - create new class - open package selection dialog in new class wizard - only the default package is schown (if you select this package you even get a warning that the usage of default package is discouraged) - File a pr against JDT/UI What about not using the search infrastructure at all and do something like in the following attachment?
Created attachment 29775 [details] don't use search infrastructure
The null check on filter is due to my paranoia;-) It's not realy required.
It is the choice of the client if a default package is shown or not (-> flag). So in the case of the new type wizard, we obviously should not show the default package. So I thought the problem we have is the scenario: User wants default package, but no search matches. If we have search matches, the code in PackageSelectionDialog line 115 will add one. Your patch in comment 12 isn't accurate as fScope.enclosingProjectsAndJars() doesn't fully describe a search scope. These are the roots, but the scope is more complex than that.
Created attachment 30763 [details] proposed fix After fix of bug 117020 empty packages are returned by search and the old implementation can be replaced by the new one.
patch released > 20051129 This adds new API JavaUI.createPackageDialog( Shell parent, IRunnableContext context, IJavaSearchScope scope, boolean multipleSelection, boolean removeDuplicates, String filter) Vikas, is that serving your needs?
(In reply to comment #16) Yes this looks good. Thanks.
Marking as verified then (I20051213-0010).
