RE: [mylar-dev] issue-tracking repositories proposal

["Mik Kersten" <beatmik@xxxxxxx>]

As Eugene indicates, Mylar’s goal is to make it easy to manage task context, so we are focusing on abstractions for manipulating context and trying to do as little defect/source repository work as possible until we grow the number of committers.  Our goal for the user study releases is to make sure that Mylar works well for a common Eclipse configuration (Bugzilla, CVS).  But as soon as someone signs up for extending Mylar to another system, e.g. Subversion, we will actively support them and by doing so turn those abstractions into API and extension points.  Prompted by Jeff Pound we have started this for the Task List, which now has extension points for adding new kinds of categories and tasks (no common query support yet, but that won’t be too hard).   

 

So for things like the Resolve & Commit wizard we will keep in mind that it should be generic, but as Michael points out it won’t actually be generic until there is a second driver.   But anything generic that we implement in order to enable more seamless interaction with tasks and context (e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=58646) we will be happy to contribute to Platform/Team as patches.

 

Mik

 

---

From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
Sent: August 18, 2005 12:06 PM
To: Mylar developer discussions
Subject: Re: [mylar-dev] issue-tracking repositories proposal

 

Michael Valenta wrote:

The problem is that, in the Platform, we only have one example to work from and that is CVS.

 What about ClearCase integration? Isn't it done by IBM?

So, we could create an API for invoking the CVS commit wizard and place it in the Team plugin and call it generic. However, would the API actually be generic enough to be implemented by other repository providers or used by other clients? Maybe it would and maybe it wouldn't. And that is the problem. So, the answer to your question is that we would consider adding generic API to Team if it has the consensus of a significant number of repository providers and a significant number of potential clients. Obtaining this concensus is the difficult part. JSR 147 is one such effort and it has been a long time in the making and still has not reached the finish line.

  I agree with you that crating generic API is a difficult task. However we have slightly different situation with Mylar. The thing is that Mylar is only interested in very specific aspects of the version control integration. What I'm suggesting is to identify these aspects and expose them in a Team API, so other providers can implement them (perhaps optionally).

  The first important aspect is invocation of the Commit Wizard.

So, the path I would suggest you take is this:

1) Define the generic API you would need in Mylar  (or some other suitable plug-in that Mylar can depend on).
2) Create implementations for CVS, SVN and whatever other open source repository providers you care to test with. These could each be placed in separate plugisn so that users could grab the one for the repository they are using.

If, at some future time, others find the API useful, it could be pulled out of Mylar and placed in a more general plugin for others to use. Also, if at some future time, a generic repository API becomes available, the Mylar API could be bridge or replaced by this new API. Who knows, given time, it may evolve into a generic API that lives in the Platform.

  It will be a really huge effort. You know the complexity of CVS provider and I can tell you that Subversion is not any simplier.
  I'm having difficult time to convince Subversion developers to at least try to be as close to CVS as possible and getting a huge resistance because CVS "does not set a standard", so they prefer to keep UI close to other SVN tools.

  So, I believe that it would be better to define high-level integration actions needed for Mylar that has formal similarities (commit, update, etc) and go from there.

  regards,
  Eugene

Eugene Kuleshov <eu@xxxxxxxx>
Sent by: mylar-dev-bounces@xxxxxxxxxxx

18/08/2005 02:16 PM

To	Mylar developer discussions <mylar-dev@xxxxxxxxxxx>
Subject	Re: [mylar-dev] issue-tracking repositories proposal

Michael,
Sorry, I meant research in very loss terms (i.e. we developed the original prototype and had some discussions about what might be possible). There is no supporting documentation. As for your comments on where to store the Mylar context, I have had conversations about this with others and the conclusion was that you probably don't want to store it in Bugzilla since it only has meaning from inside Mylar. It would probably be better for Mylar to provide a link from a bug to the context which is stored using another means (perhaps in CVS;-).

As for the commit scenario you describe, you could probably do it using the CVS CommitWizard class. All you really need is the ability to trigger the wizard (which already exists but in non-API form) and the ability to prime the comment (this isn't there but shouldn't be a large modification). You may also need to get some return code from the wizard to indicate the result sof the commit (again, you would probably need to add this).
  Is there are chance that Team plugin can expose a generic API for invoking commit wizards? Then Subclipse and other version control providers can contribute to this API.

 regards,
 Eugene