Community
Participate
Working Groups
It would be helpful to have an extension point for specifying a duplicate detector to use for a particular repository type and/or project. We have some experimental duplicate detection software we'd like to make available but its awkward to contribute without the extension point. We can work on contributing the extension point.
It seem like a great idea. I also want to remind that current search for duplicates don't work too well...
Nope, the current search is way too fragile (bug 161877) and this should make it easier for someone else to contribute better heuristics. If we end up with multiple extensions (e.g. one for simple Java, another for Ruby, another for fancy NLS) we can provide UI for allowing the user to choose which one to use. But the key thing is that we get such an extension point. Gail: if you guys are able to contribute within the next two weeks we can get this into 2.0.
One way to do this is to have plug-ins specify an AbstractDuplicateDetectionCollector class which would extend SearchHitCollector. Another is to have an abstract class or interface that extends ISearchQuery with duplicate-detection specific stuff. A good example of how to make an extension point of this sort is ..tasks.ui/schema/projectLinkProviders.exsd. An implementation of the extension point could look like this: <extenion point="org.eclipse.mylar.tasks.ui.duplicateDetectors> <detector id="org.eclipse.mylar.java.duplicateDetector.stackFrame" class=".." name="Naiive Java Stack Frame Duplicate Detector" image="icons/javaStackTrace.gif"/> </extensions> For UI for allowing the user to select a duplicate detection the PDe validation on the Plug-ins tab of a Workbench runtime configuration is probably a good example. It has the default "Validate Automatically Prior to Launching". We could have a similar drop down in the NewBugzillaTaskEditor (eventually this should be generic) and it could simply remember the last duplicate detector that was used.
Here is a context to get you started.
Created attachment 67716 [details] mylar/context/zip
BTW, I think PDE's validate drop down is one of the worst UI pieces. It may look cool, but it is totally counter intuitive to have toolbar-like icon inside of dialog. Not to mention that their UI can't be accessed without mouse.
I will work on this, but I'm not able to assign it to myself - could someone else assign it to me?
(In reply to comment #6) > BTW, I think PDE's validate drop down is one of the worst UI pieces. It may look > cool, but it is totally counter intuitive to have toolbar-like icon inside of > dialog. Not to mention that their UI can't be accessed without mouse. I agree. I was using it as an example of a drop-down button showing up in a page, but neglected to mention that the end result of their UI is way worse than it used to be as a single button. I still think that we can take the button approach, but if not perhaps there needs to be a combo where you select the detector and a "Search for Duplicates" button.
I wonder if detector selection should be in the repository configuration...
It seems like we need to support both generic (e.g. Java heuristics) and connector specific (e.g. require executing special WS calls) duplicate detection. The easiest way to do this is probably to add the following optional attribute to the extension point: connectorKind="bugzilla" Then if the kind were specified, the task editor would only show that detector if it was applicable.
what's the deadline to get this into 2.0M3? I keep thinking it's almost done and then finding something that I haven't quite done right...
The next release is RC1. The deadline for getting it in is next Friday. Which means that we should be iterating on a reasonable version of it early next week.
Created attachment 70530 [details] extension point for duplicate detectors This patch provides an extension point for duplicate detectors and converted the Stack Trace duplicate detector to use this extension point. I will create some documentation for people who wish to use this extension point with their own duplicate detectors.
Created attachment 70531 [details] mylar/context/zip
I think this patch will merge with all the Task changes that have just gone in. It would be great if it could get in before the name change...
Patch applied. I will review this more closely after the rename.
Meghan: I had to do some additional merging manually, you'll need to review your code after the rename is done.
ok, thanks Mik. I will.
Meghan: note that I moved your extension point to ..mylyn.bugzilla.ide.
I updated the extension schema to require a java element vs string so that you must declare a class that extends AbstractDuplicateDetector.
thanks Rob, that is definitely better.
We still need to fix the layout and make sure that the duplicate detection buttons/toggle is not shown if there is no duplicate detector installed.
Upon creating a new task that is not a bugzilla task, the stack trace duplicate detector is in the list of detectors. This seems to be the case since all of the duplicate detectors are added to the editor and there is no notion of the repository kind that they support. Maybe a method like canSearchDuplicates(String repositoryKind) could be added so that we ensure that the correct duplicate detectors are used.
I'm working on a related issue this morning and can try to tackle this one too.
BTW, please watch out for the borders on the forms.
Yup, the border stuff is tricky. Gail: don't worry about this, when Rob reviews he can make sure it works properly across platforms and themes.
(In reply to comment #23) > Upon creating a new task that is not a bugzilla task, the stack trace duplicate > detector is in the list of detectors. This seems to be the case since all of > the duplicate detectors are added to the editor and there is no notion of the > repository kind that they support. Maybe a method like > canSearchDuplicates(String repositoryKind) could be added so that we ensure that > the correct duplicate detectors are used. The default behaviour is that every duplicate detector is shown for every new task. I don't know much about the other connectors, so let me know if this should be changed. There is an optional 'kind' attribute that can be specified in the xml for the duplicate detector, and then each subclass of AbstractNewRepositoryTaskEditor can override the getDuplicateSearchCollectorsList() method and return a list that only includes the duplicate detectors that are appropriate for the repository (by checking the 'kind' attribute). Should I add that to the Trac and Jira connectors so that the Stack Trace duplicate detector only displays for the new Bugzilla tasks?
(In reply to comment #25) > BTW, please watch out for the borders on the forms. Eugene - could you elaborate? I'm not sure what you mean.
(In reply to comment #22) > We still need to fix the layout and make sure that the duplicate detection > buttons/toggle is not shown if there is no duplicate detector installed. the 'Search for Duplicates' button and combo box should only be displayed if at least one connector is installed. what do we need to do for the layout?
I think the patch on bug 156061 will show just a label if there is no duplicate detector registered. I think it is now set up to only show the stack trace for Bugzilla but this still needs to be verified.
Further changes to this need to wait post 2.0. Meghan, Gail: could you summarize if there is anything left here that you need?
Please note that current support been only added to Bugzilla editor, so we lose stack trace detector for jira and trac I wonder if the following method should be pushed to the super class. protected Set<AbstractDuplicateDetector> getDuplicateSearchCollectorsList() { return TasksUiPlugin.getDefault().getDuplicateSearchCollectorsList(); } Anyways, that change need to be included into the porting guide, because without adding this getDuplicateSearchCollectorsList(), detectors created by connectors aren't being picked up.
Apparently, current duplicate detector extension point and corresponding api is missing repository type. So, StackTraceDuplicateDetector for bugzilla should use "bugzilla" kind value and connector-specific editors should filter list of detectors according to the kind.
Core work here is done. Additional needs can go on new bugs.
