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 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).
regards,
Eugene
PS: btw, Polarion folks may have something of their own for such commit
dialog...
FSauer@dsthealthsolutions.com wrote:
> > An example issue is to picture a scenario where I have plugins for
> > Bugzilla, JIRA and some other issue tracker all installed. Which one
> > does Subclipse interact with?
>
> All of them. Which one is used is determined by the svn
> property 'bugtraq:type' This is correlated with an extension
> of the same type, which is then used in the commit dialog.
>
> So the hierarchy of the stuff you're committing determines which
> bug tracking UI to use - if any.
>
> > There has to be some kind of project-level configuration for this.
>
> Agreed, I made that part of the 3rd plugin that integrates JIRA with
> Subclipse.
> It's a project properties page where you set your JIRA server and pick
> a project
> and component to associate with. This results in the appropriate
> bugtraq:*
> svn properties being set on the project. (including the above
> mentioned bugtraq:type)
>
> Frank
>
> P.S. I agree also that Mylar is probably the correct way to go with
> this. Just watched
> the webcast and it looks awesome.
>
>
>
> *Mark Phippard <markphip@gmail.com>*
>
> 11/27/2006 01:01 PM
> Please respond to
> dev@subclipse.tigris.org
>
>
>
> To
> dev@subclipse.tigris.org
> Subject
> Re: [Subclipse-dev] PATCH: new extension point for issue
> tracking integration
>
>
>
>
> FSauer@dsthealthsolutions.com wrote:
> >
> > I've modified the subclipse ui because we had a requirement to
> > integrate with the Jira issue tracker,
> > so that the commit dialog in subclipse actually queries for and shows
> > the Jira issues. Now, in order to
> > not pollute Subclipse with Jira dependencies, I did NOT add all this
> > code to the subclipse ui plugin,
> > but instead created a new extension point:
> > org.tigris.subversion.subclipse.ui.bugtrackingui, which
> > third party plugins can use to contribute a UI to the commit dialog,
> > like this:
> I am in favor of the concept here (using an Extension Point). I think
> that you should try to get together with the Mylar people though to get
> an idea of what they are doing. I think an idea was for them to define
> these extension points, and then we would add the code to use it.
>
> An example issue is to picture a scenario where I have plugins for
> Bugzilla, JIRA and some other issue tracker all installed. Which one
> does Subclipse interact with? There has to be some kind of
> project-level configuration for this, as there is for team providers.
> Mylar is working on defining that stuff.
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Mon Nov 27 21:07:50 2006