RE: [mylyn-integrators] Basic questions about extending AbstractTask

["Tom Bryan (tombry)" <tombry@xxxxxxxxx>]

Robert Elves wrote on Monday, April 28, 2008 5:01 PM:
> Sorry for the slow response on this.  

No problem.  Better late than never!  :)

> Before I dive into answering
> these questions, I should let you know that Mylyn 3.0 will be
> available on June 25th and the api for dealing with these issues will
> be different. Is there any chance you could postpone your
> implementation 

Unfortunately, no.  Our target is Eclipse 3.3 at this time, and there
are some internal deadlines that are pushing this effort.  I'll double
check with the program manager, but it looks like I'll have to implement
right now on Mylyn 2.3 and migrate later to Mylyn 3.0.  

> To answer your question,  as you've observed, the connectors don't
> store the majority of the information on AbstractTask. All your
> repository task information should be stored on RepositoryTaskData
> objects. 

Yes, thanks.  It's nice to know that I'm on the right track.  :)

I was kind of hoping that the Integrator Reference on the wiki would be
closer to an actual step-by-step HOWTO instead of just a broad
guideline.  (It's certainly appreciated, of course!)  I'm trying to keep
track of my steps along the way so that I can improve the wiki when I'm
done...2.3.0 api only, I'm afraid.

> The same RepositoryTaskData that is returned by
> AbstractRepositoryConnector.getTaskData().  The RepositoryTaskData
> object has a number of accessor methods for things common to most
> issue trackers such as comments, attachments etc, but you can store
> abitrary attributes via RepositoryTaskData.addAttribute(String key,
> RepositoryTaskAttribute attribute).   

Thanks.  That's what I thought.  I was just a little confused between
data that was ending up in real fields, like JiraTask.key, and data that
was being sent to RepositoryTaskData's attribute map.  Our system has
dozens of distinct fields that we track for various processes and
metrics.  I'll just stuff all of the non-common attributes in the
RepositoryTaskData's attribute map.  

> Your task editor implementation
> will then get an instance of this RepositoryTaskData to work with, you
> can then interpret your connector specific attributes and display them
> accordingly.

Ugh...yes, I'm trying not to think about the editor until I have queries
working correctly. ;-)

Thanks, again.

-- 
Tom Bryan <tombry@xxxxxxxxx>
Cisco Systems