[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mylyn-integrators] No externalizer for query - What did I miss?
|
Dennis Rietmann wrote:
Hi Eugene,
Thanks again for the additional explanations and pointer. In fact the
lack of documentation is one of the biggest problems for me when
implementing my connector.
This is a well known issue and it is planned to be addressed in 3.0
timeframe. Mik posted some explanation and recommendations on bug 195450
Sometimes the javadoc is even wrong like in
AbstractRepositoryConnector.markStaleTasks - it says that it returns a
set of changed tasks but the method actually returns a boolean (I use
the Mylyn 2.x stream for Eclipse 3.3).
Right. Please comment on bug 195450, so it will be tracked
195450: improve documentation for APIs and extension point definitions
https://bugs.eclipse.org/bugs/show_bug.cgi?id=195450
The query synchronization API is probably one of the most twisted APIs
in Mylyn. In my recollection there was few iterations trough that API at
the end of 2.0 cycle and it seems like javadoc got out of sync.
Anyways, the return value of markStaleTasks() method is simply a flag
saying if there been any changed tasks since last synchronization, so
queries need to be synchronized also. More over, implementation of that
method should use setStale() flag on tasks from collection passed as a
tasks parameter of that method (so, the description on the method
javadoc is also outdated) to specify if these tasks need to be updated
from the issue tracking system.
Note that depends from your issue tracker capabilities you can also
download and update task data for these changed tasks right in the
implementation of markStale() method to save additional round trips to
server, but then you shouldn't set the stale flag. You may still have to
return true to refresh queries (because new tasks could be added to
query or tasks could be dropped from query).
Compare, for example, implementation of this method in Bugzilla and
JIRA connectors.
Generally I would suggest to look at the callers of the API methods
(Ctrl-Shift-G) you are implementing and then to the other implementors
from other connector (Ctrl-T) on the API class. That should give you
some basic idea about current API contracts and the usage.
regards,
Eugene