Eugene,
I believe what you are saying is that it would be nice to have a well know
place where such API could live so that clients and providers know where
ot find it. Given that the Team component is part of the SDK, it would
definitely be easy for clients to find the API. However, there is a cost
and that is that the people with a vested interest in the API (e.g. Mylar)
would loose a fair bit of control over the evolution of that API. I think
that, at this stage, Mylar is the logical place to do this type of API
exploration. If the API gains enough momentum then it may make sense to
move it out of Mylar and into a separate component. If it becomes the
defacto standard for Eclipse, it may even make sense to include it in the
SDK. This can all be done without the API ever being part of the Team
component (hypothetically, since suspect it would be grouped with the Team
component if it was adopted as part of the SDK).
Michael
Mark Phippard <markphip@gmail.com> wrote on 11/27/2006 03:42:49 PM:
> Eugene Kuleshov wrote:
> >
> > Cross posting to Mylar's dev list.
> >
> > I actually think that this dialog, API and extension points belongs
> > to the Eclipse's Platform Team component.
> > Ideally we should have some kind of abstract class available to all
> > interested parties and that class should take care of the list of
> > resources for commit. However comment area and additional stuff that
> > specific to issue tracking systems should be pluggable. So, 3rd party
> > plugins can register and provide their own implementation.
> > This can be of course implemented in Mylar, but I think that not
> > everybody would want dependency on Mylar components. Michael can
> > correct me, but I am not sure if there is an enhancement request for
> > Eclipse. Though I recall there is a request to make commit an API.
> I am not sure if a common commit dialog would be of that great of
> benefit. I suppose it would depend on how many cool additions it could
> have. Such as issue tracking integration, and maybe integrated compare
> view? But as an example, there are some bits of essential SVN-specific
> info we show for the files that I would not want to give up. That means
> we have to supply that piece of the UI, at which point what is the
> common dialog still providing us?
>
> Main benefits would be if the extension points could provide instant
> integration.
>
>
> > I also think that using bugtraq:type property in Subclipse may not
> > be flexible enough. For instance it will be a duplication of the same
> > info that Mylar or Maven already have. Note that Mylar already can
> > link issue tracking repositories to Eclipse projects (though that may
> > not work for remote resources yet) and that link can be made
> > extendable to actually pull that info from Maven's metadata (pom.xml).
>
> I assume if we integrate with a Mylar extension point we would not need
> any SVN properties. It would just recognize and use the Mylar config.
>
> Mark
Received on Mon Nov 27 22:07:47 2006