Bug 155279

Comment 1 Tomasz Pik 2006-08-28 16:01:35 EDT

Here's what I'd ideally like to see (I'm not sure it's in scope of this issue...):
in current BugzillaQueryTest there's a parameter for TaskRepository constructor pointing that it's a Bugzilla task repository.
Then there're Bugzilla related BugzillaSearchOperation class and very specific for Bugzilla query string.
Ideally only this parameter for TaskRepository should be Bugzilla-related, the rest of things should be independent.
So I think something like Search class (concrete subclass of AbstractRepositoryQuery in org.eclipse.mylar.tasks.core package?), where there's a plenty of properties that may be set (description, startDate, endDate, priority, reported, asignee what else?) and code beyond TaskRepository is able to translate those properties into issue tracker-specific query (like Bugzilla query string), execute search and translate response into list of Task classes.
Having this Maven will be able to use project configuration (see http://maven.apache.org/ref/current/maven-model/maven.html#class_issueManagement, system will map to 'kind' parameter) to operate on issues using mylar code.

Comment 2 Jimisola Laursen 2006-08-28 21:57:47 EDT

+1

I think Tomasz Pik hit the nail on the head with comment #1.
To be honest, this is how I thought that the Mylar Task API was constructed before I started looking at the code.

Once I've configured a TaskRepository instance I want a common and independent way to of searching the issue tracker / task repository for tasks/bugs/issues.

Comment 3 Robert Elves 2006-08-31 14:58:34 EDT

I agree that this is the right direction to move the generic task/repository api.  Short term, in terms of Bugzilla, I just committed the separation of search core and ui.  
AbstractQueryHitCollector is now in tasks.core and we have two collectors in Bugzilla one BugzillaResultCollector and BugzillaSearchResultCollector ( I'll probably rename these though). The first is for non-ui result collection and the second can be used for ui (task search) result collection. Note there may be some refactoring of the ui search since it now seems over complicated.
See bugzilla.tests.headless.BugzillaQueryTest for an example of querying a repository for query hits. 

For now AbstractQueryHit isn't handed a tasklist but BugzillaQueryHit objects are...we may want to pull this up into the AbstractQueryHit so the other connectors can implement the split as well.

Comment 4 Robert Elves 2006-08-31 14:58:47 EDT

Created attachment 49202 [details]
mylar/context/zip

Comment 5 Steffen Pingel 2006-09-01 14:11:59 EDT

As I have outlined in bug 154876 comment #9 the task list and repository manager needs to made accessible from core in order to move Bugzilla/TracRepositoryConnector to core. We could also pass the task list to AbstractRepositoryConnector to avoid moving singletons into core. Mik, are there any plans to do so?

I think the Eclipse search is rather Eclipse/UI specific and doesn't necessarily be made available in core. AbstractRepositoryConnector.performQuery() should provide sufficient support for repository queries. 

I agree that there is a need for a generalized search query representation that can be mapped to a repository specific one by connectors. Maybe we can implement this similar to AbstractAttributeFactory.

Comment 6 Mik Kersten 2006-09-07 21:57:30 EDT

This move is now in progress and largely completed, will post more soon.

Rob: make sure to make AbstractRepositoryHitCollector concrete, possibly with a single generic subtype that's coupled to the search UI.

Comment 7 Mik Kersten 2006-09-07 21:59:23 EDT

Rob: you should also consider getting rid of BugzillaSearchEngine.

Comment 8 Robert Elves 2006-09-10 20:21:01 EDT

Update: QueryHitCollector is the solid non-ui query hit collector. SearchHitCollector (extends QueryHitCollector and implements ISearchQuery) provides the search and hit collection on the ui side - passed to NewSearchUI.runQueryInBackground(...). This collector takes, among other parameters, an AbstractRepositoryQuery,  executes this query and collects the hits. (SearchHitCollector.getHits() to retrieve them).  

Todo: 
- Update headless tests to show querying using connector.performQuery (Monday)
- BugzillaSearchOperation, BugzillaSearchEngine, etc are still there just to appease code in the sandbox for now but will eventually be removed.
- Generic query construction as per comment#1
- pull up common functionality from performAction in wizard pages 

Comment 9 Robert Elves 2006-09-11 12:21:26 EDT

Created attachment 49843 [details]
mylar/context/zip

Comment 10 Mik Kersten 2006-09-13 22:54:22 EDT

Rob: You should probably move BugzillaSearchOperations and BugzillaSearchEngine into sandbox.

For the common query construction, I wonder if we can just rely on a URL-style parameter list?  This approach is very flexible, can be used as a String, and has the big benefit of interoperability with the web UI.  REST is good ;)  It also sidesteps the problem that there are significant differences in the search parameters supported by task repositories (e.g. Trac can't do date ranges), potentially bloating AbstractRepositoryQuery without sufficient utility.  I realize that a headless tool might want some code for constructing that String, but perhaps the best way to support that is by having the connector expose some of the code currently stuck in the search page.  Thoughts?  

Comment 11 Robert Elves 2006-09-14 16:18:22 EDT

Sound like the right solution to me.  I've created bug#157391 to track generic query construction.

Comment 12 Robert Elves 2006-09-14 18:55:20 EDT

Marking resolved. BugzillaSearchEngine and Operation moved to sandbox.