[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mylar-dev] Bug 160928: [connector] MKS Integrity
|
I've attached several screenshots of the MKS Worktray and the Web UI to
the bug. I hope those help to give an idea of how things work on our
end of things.
It seems as though the generic web connection works well, and we can
probably get away with using the web interface for editing and creating
tasks (I'm going to adopt your "task" terminology from hereon, just to
make things easier). That may even work more smoothly than what we have
in our current integration. We currently have no real offline support
for tasks, so this would be a benefit to integrating with mylar as well.
I'm under the impression that the majority of our users are unfamiliar
with the MKS Worktray aspect of our integration (it's very well hidden),
and mostly use the source repository end of things, so removing the MKS
Worktray completely and adding any missing functionality somewhere else
(we also have a change package management view) wouldn't be the end of
the world.
How do queries work with Mylar? Can the connector be designed so that
you retrieve a list of queries from the server, then have the list of
visible tasks be based on the currently active query? Our software
allows users to save queries, which are later available to themselves or
other groups of users. I currently have 480 queries available to me,
and rebuilding even a small portion of those to be able to retrieve
relevant groups of tasks would be a huge pain. Users of MKS Integrity
will only ever see a list of tasks as returned by some query (or a text
search), though you can view individual tasks directly. We do our
degree-of-interest in tasks based on queries, whereas (from my
understanding) your software does degree-of-interest in the code base
based on active tasks. Combine the two, and you have a killer
productivity app, which only lets you see what's currently relevant. :)
Thanks for your input,
Kristina Taylor
-----Original Message-----
From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Mik Kersten
Sent: Wednesday, November 15, 2006 1:39 PM
To: 'Mylar developer discussions'
Subject: RE: [mylar-dev] Bug 160928: [connector] MKS Integrity
Hi Kristina,
Great to hear that you're interested in integrating with Mylar.
> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx
> [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Kristina Taylor
> Now, all that being said, I have some questions:
> 1) Does the integration need to be released as a part of your product,
> or can it be part of our existing eclipse integration?
I think that it would be best to release this integration as part of
your Eclipse integration, since it is targeted at the MKS user
community. What we could do on our end is link it from our site and
make sure that it's easy to install for new Mylar users who are on MKS.
> 2) We currently have our own version of an Eclipse Task list, called
> "MKS Worktray". It has the ability to create new issues, edit issues,
> run a query, and deal with change packages. How much of this
> functionality would we be able to integrate via "rich editing"? Can
> Mylar connectors be organized so that our UI would be called when a
> user tries to edit a task?
Could you send some screenshots of the MKS Worktray in action? That
would give me a better sense of how best to approach the integration.
The Mylar Task List has a considerable amount of functionality that is
related to rich editing. For example, it shows notifications of
incoming changes, and indicates when a query synchronization failed. It
is also the anchor for managing the offline support, since only the
tasks that the user has read are stored offline, only changes tasks are
synchronized, and all of this state is maintained in the TaskList. Now,
we do have a loosely-coupled architecture so you could actually use the
TaskList (in ..mylar.tasks.core) without using any of the UI stuff or
having your users install it, but we would need to figure out how much
of the UI stuff you would need to duplicate for MKS Worktray, and
whether it is easier for you to extend or integrate with Mylar's Task
List.
One thing to consider when deciding whether to integrate with or to
replace the functionality of the Task List is whether your developers
will want the Task List anyway. In our experience developers work with
three kinds of
tasks:
* The issues and tasks that make up their project (i.e. in MKS
integrity).
* Bug reports and enhancement requests that they watch and create for
the other frameworks that they use (e.g. bugs against Eclipse, JEE,
Spring).
* Personal tasks and todos they need to make for themselves (via Mylar's
Task List).
For this reason a fundamental part of our approach is to give developers
a single view for managing all of their tasks, and to make it easy for
vendors to customize the content of the Task List and rich editors to
meet their needs (e.g. as JIRA does with custom task icon type
overlays). This is discussed some in the following article:
http://www-128.ibm.com/developerworks/java/library/j-mylar1/
The other thing to consider is integration with Mylar's automatic
context management facilities. Again, this is possible to integrate
with a custom view, but the Task List has been streamlined around the
interaction needed to make task activation easy. More on that is here:
http://www-128.ibm.com/developerworks/java/library/j-mylar2/
> 3) What level of effort (# of developer days) do you think would be
> required for a reasonably proficient Java developer already familiar
> with Eclipse?
Integrating MKS queries either via a web connector template or via a
customized connector should not be much work, a week at most. The
amount of work for the rich and offline editing we would need to figure
out the integration strategy wrt to question (2) above (e.g. if it
involves re-implementing rather than extending substantial parts of the
Task List it
could be quite a bit of work since the ..mylar.tasks.ui is 25 KLOC).
Mik
--
Mik Kersten, http://kerstens.org/mik
Mylar Project Lead, http://eclipse.org/mylar
_______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev
