Hi,
There is an ongoing discussion in Mylar project mail list about common
integration API for activities specific to version ontrol systems. See
archive at http://dev.eclipse.org/mhonarc/lists/mylar-dev/maillist.html
Mylar (http://eclipse.org/mylar/) is a new but very impressive Eclipse
research project. It allows to make IDE activities context or task
aware. E.g. open close opened editors when switching between tasks,
filter out Package Explorer, Outline, Problems, etc. from elements not
related to the curntly selected task, and so forth, and so on. You can
see a flash demo at http://eclipse.org/mylar/doc/mylar-0.3-demo.html
One of the important parts is to have tight integration with other
tools such as issue tracking repositories and version control
repositories. Here is typical scenario:
-- Add query for issue tracking repository into Mylar task list (e.g.
filtered by priority or by name).
-- New query items can be activated as tasks and until active all
interaction is monitored for level of interest.
-- When done research and/or changes, user can choose "Resolve Task"
action, then Mylar can do several things (not all implemented yet):
-- check if project is connected to the version control system it can
automatically kick a commit wizard/dialog for resources changed within
context of the selected task and also fill in the comment text with the
issue title and/or issue details from issue tracking systems
-- for issue tracking repository it can also submit a comment with
list of changed files, automatically create and attach patch to the
issue and/or close/resolve issue in the issue tracking repository
As you can see in the Mik Kersten email below, currently Mylar is
focused to support CVS and Bugzilla repositories, but they are willing
to help to integrate other providers and I think that Subclipse should
be integrated. It is necessary to get an agreement on a common high
level API that can be used by Mylar, so CVS and SVN providers would play
nicely with Mylar.
regards,
Eugene
-------- Original Message --------
Subject: RE: [mylar-dev] issue-tracking repositories proposal
Date: Thu, 18 Aug 2005 18:16:24 -0700
From: Mik Kersten <beatmik@acm.org>
Reply-To: Mylar developer discussions <mylar-dev@eclipse.org>
To: 'Mylar developer discussions' <mylar-dev@eclipse.org>
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@eclipse.org
[mailto:mylar-dev-bounces@eclipse.org] *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@md.pp.ru> <mailto:eu@md.pp.ru>*
Sent by: mylar-dev-bounces@eclipse.org
<mailto:mylar-dev-bounces@eclipse.org>
18/08/2005 02:16 PM
To
Mylar developer discussions <mylar-dev@eclipse.org>
<mailto:mylar-dev@eclipse.org>
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
Received on Fri Aug 19 15:32:59 2005