Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mylar-dev] Bug 160928: [connector] MKS Integrity

Hi Kristina,

 

It sound like MKS is similar to JIRA, in that it relies on a large number of predefined queries either available to everyone or per user account.  Our JIRA Connector supports this by allowing the user to select a predefined query on the server and add that to the Task List, in addition to supporting custom query creation from within Eclipse:

 

 

So this should be straightforward to do by using a similar approach to JIRA.  If we have two clients doing this we can make it a generic facility in the Tasks Framework as has been requested:

 

155487: add generic support for retrieving saved queries

https://bugs.eclipse.org/bugs/show_bug.cgi?id=155487

 

Great to hear that there is complementary overlap between Mylar’s Tasks Framework and your integration needs.  We can discuss generic connector needs further here, but I’ll also respond on the corresponding bug report.

 

Also note that in terms of adopting these APIs it is best that you wait until after the 1.0 release which is scheduled to be announced on December 11th (contingent on the final steps of the corresponding eclipse.org IP approval process). 

 

Mik

 

> -----Original Message-----

> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]

> On Behalf Of Kristina Taylor

> Sent: Wednesday, November 15, 2006 1:53 PM

> To: Mylar developer discussions

> Subject: 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

> _______________________________________________

> mylar-dev mailing list

> mylar-dev@xxxxxxxxxxx

> https://dev.eclipse.org/mailman/listinfo/mylar-dev


Back to the top