Community
Participate
Working Groups
The option "Add to Java Search" is very handy. So handy, one wonders why search just doesn't work this way by default. But the option is too hidden. Having it squirreled away in the Plug-ins view is just too obscure vis-a-vis its utility. I didn't know it existed until recently, and even then I keep having to ask where it is. Second, it works based on the set of selected plugins, but this is more precision than (most) people need. Why would I only want to, from here on, search in only a subset of plugins? Suggestions: 1) Make it the default behaviour. People can always filter the results. 2) A variation could be that we always search plugins which loaded projects are dependent on. 3) Put it in the preferences (that's where I always think to look) 4) Add it as a menu to the jars in the packages view (that was the next place I tried). I like this option least for the reasons above but at least might be easier to find.
*** This bug has been marked as a duplicate of bug 81281 ***
I think this should be added to the Package Explorer's PDE menu - at least that's where I was looking for it.
Doing something simpler like adding it to the PDE context menu could be useful and not too difficult. Maybe someone would like to do this for bugday?
I don't think it is too easy as it needs to be contributed on the JARs inside the PDE container and that JAR needs to be converted to an IPluginModelBase and there seems to be no such adapter on IProject.
Nothing planned for 3.5
Created attachment 131092 [details] Inital stab at fix This almost does the trick except for the issues mentioned in my previous comment.
Proposal: The "External Plug-in Libraries" should track the active target platform. * Add a preference to "Add active target platform to Java search". The preference should be added to the the top level PDE preference page (Plug-in Development), in the existing "Target Definitions" group. * When this preference is checked the LoadTargetDefinitionJob should update the SearchablePluginsManager when run. For this reason the preference should be managed by PDE core (not UI). * The default setting should be off (for backwards compatibility), and we should ensure that it gets initialized properly.
Before we do this, is there a better way to do this than our invisible project? Also, note that these bugs are related 81281: automatically add target plugins to Java search? https://bugs.eclipse.org/bugs/show_bug.cgi?id=81281 206723: Java search participant is not scoped https://bugs.eclipse.org/bugs/show_bug.cgi?id=206723 Also, we should be careful to make sure the searchable plugins manager deals with multiple versions of bundles. I recall it only using the latest version available. Also, I'm actually fine with making this the DEFAULT and maybe not having a preference. From my experience, this is the behavior that people want and expect.
(In reply to comment #8) > Before we do this, is there a better way to do this than our invisible project? I don't see a better way currently. Java search is based on projects/Java model elements (and displaying search results is too...). > Also, note that these bugs are related > 81281: automatically add target plugins to Java search? > https://bugs.eclipse.org/bugs/show_bug.cgi?id=81281 Yes, perhaps we should dup this one against bug 81281. > 206723: Java search participant is not scoped > https://bugs.eclipse.org/bugs/show_bug.cgi?id=206723 > Also, we should be careful to make sure the searchable plugins manager deals > with multiple versions of bundles. I recall it only using the latest version > available. We should just use all bundles in the target (if there are dups, fine). > Also, I'm actually fine with making this the DEFAULT and maybe not having a > preference. From my experience, this is the behavior that people want and > expect. I think the issue is how the existing "Add to Java search" actions play with the new preference. Should we just have the preference and no actions? If so, I think it should be on by default.
(In reply to comment #9) > (In reply to comment #8) > > Before we do this, is there a better way to do this than our invisible project? > > I don't see a better way currently. Java search is based on projects/Java model > elements (and displaying search results is too...). Dani, any thoughts? > Yes, perhaps we should dup this one against bug 81281. Let's dupe it. > I think the issue is how the existing "Add to Java search" actions play with > the new preference. Should we just have the preference and no actions? If so, I > think it should be on by default. Ok, let's do that. I think that's better behavior. We need to think about how to handle this if we end up with multiple targets per project too (ie., just add everything across the targets?)
(In reply to comment #10) > > I think the issue is how the existing "Add to Java search" actions play with > > the new preference. Should we just have the preference and no actions? If so, I > > think it should be on by default. > Ok, let's do that. I think that's better behavior. > We need to think about how to handle this if we end up with multiple targets > per project too (ie., just add everything across the targets?) Perhaps we should reveal the setting in the Plug-ins view toolbar as a toggle action as well (that controls the underlying preference). That way if people are looking for the old action they'll still find it.
For multiple targets, we could consider having multiple "external libraries' projects, one for each target in the workspace. The only problem then would be that there would be only one global preference that would potentially control a lot of entries in the java search. I agree with Darin's last suggestion. We have a pref on the main page, it can default to ON (unless we have performance concerns). Then put a checkbox option in the view's menu so people can see the work is already being done for them.
*** Bug 81281 has been marked as a duplicate of this bug. ***
>Dani, any thoughts? Darin's right, there's currently no other way to do this (except of course importing the plug-ins as binary which is what I do ;-).
Moving to M3
Ankur, do you have an updated patch? I would like to try this before we release it to the wild.
Created attachment 148129 [details] Patch After trying several approches I found this one most reliable. Let me know your thoughts. Also, could not see any fitting way to write JUnits for it.
(In reply to comment #17) > Created an attachment (id=148129) [details] > Patch > > After trying several approches I found this one most reliable. Let me know your > thoughts. > Also, could not see any fitting way to write JUnits for it. I haven't look at the fix in any detail, but I tried it out and saw two possible problems. 1) I had a target with multiple identical bundles. Adding the target to java search worked correctly. I then edited my target platform to have no bundles in it. The external libraries project continued to list all of the bundles I had previously. Turning off the preference then turning it on again did not fix the problem. I haven't debugged anything, but I'm guess that some of the target information is cached somewhere. 2) When you press OK on the dialog you get a busy cursor. I don't expect the job to take very long, but if it does, the busy cursor is not a safe thing to use. I expect that the job should be just executed in the background and if the user changes the setting again, the previous job would be cancelled if not complete. If the job needs to block the UI or prevent changes to the pref dialog (see point 3 below) we could popup a dialog like the compiler settings pref page. 3) Any ideas what would happen if the preference was changed AND the target platform was changed without pressing OK/Apply inbetween? What probably should happen is that the addtosearch job would be run twice (one for the pref page, again for the loadtargetjob). If the job had a family we could cancel any previous jobs before running.
Created attachment 148312 [details] Patch using WorkspaceJob Now using cancellable workspace job for doing the task.
Created attachment 148361 [details] Modified Patch I started reviewing Ankur's patch, then decided to just update the code as I went. I changed the following: 1) Preference page was running the job even if nothing had changed (preference pages get performOK called whether they are dirty or not). 2) You have to be a bit more careful with the progress handling. Using a try/finally to finish the task even if there is an error is recommended. worked() adds one or more ticks, it doesn't set the total. I switched to use SubMonitor which is a little more robust. 3) Created a new bug to update the help doc, which is way out of date. 4) Added a prompt asking the user to turn off the synch preference when manually removing a plug-in from search. Reminds users that as long as the preference is turned on, anything they remove might not stay that way. 5) Removed items from the java search when the target platform changes before adding new ones (changing target platforms kept the old ones and added the new ones) 6) Updated the text used. Ankur, note that we try to avoid using the term 'bundle' in the UI. Keeps us consistent until the day we switch everything over. Ankur, please review my changes.
(In reply to comment #20) > 5) Removed items from the java search when the target platform changes before > adding new ones (changing target platforms kept the old ones and added the new > ones) When a target is switched all the plug-ins from old target are removed from java search. This is present behavior. Thats why I did not care to remove them explicitly.
Ankur told me he was happy with the patch. Applied patch to HEAD.
