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