Bugzilla – Full Text Bug Listing
| Summary: | Automatic resolution of links between projects and issue repositories | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> | ||||||||
| Component: | Mylyn | Assignee: | Eugene Kuleshov <ekuleshov> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P4 | CC: | wmitsuda | ||||||||
| Version: | unspecified | Keywords: | helpwanted, plan | ||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 169788 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Eugene Kuleshov
BTW, it brings up an interesting issue. With this, we may need to allow to implicitly register repositories when projects with enabled repository resolution are added into workspace and unregister those repositories when these projects removed, closed or will change repository mapping (e.g. disconnect Subversion project)... This is sounding good, I'll look into it next week. The challenge here is that there is a tension between the way that Eclipse stores project preferences (.project, .settings) and in the way that other tools such as Maven store settings (e.g. pom.xml). The problem is not particular to Mylar, and we had the identical problem with the AspectJ IDE Framework needing to support Eclipse, JBuilder, NetBeans, and Ant, all of which had their own formats. Assuming that it's too hard to get an extensible project properties mechanism into Platform, I'm wondering if a good way to handle such cases is for something like the Maven Eclipse plug-in to transparently synchronize the settings between the Eclipse preference store and the pom.xml? The from the users' point of view the Eclipse settings would 'drive' the pom.xml settings, which would provide consistency. Thoughts? Mik, synchronization of the properties won't work. Simply because there would be two places and when both of them changed you would have to do the manual merge. So, there must be not more then one source of such settings. I don't see this as a very big deal, because you could allow pluggable persistence layer and let 3rd party plugins to provide their own strategy how these settings should be stored. Can't prioritize this for 1.0, but can help with patches if this is contributed contributed. In addition to manual repository assignment we have two additional strategies: -- using JIRA properties. Mark Phippard gave good overview of this in his blog at http://markphip.blogspot.com/2007/01/integrating-subversion-with-your-issue.html -- using Maven model So, we should probably add something like priority to the extension point I suggested in the task description. It also seems like we don't need custom panel, but instead should have some way to communicate if that information is editable or not. How about if the UI on the Task Repository page of Project Properties has two radio choices, the selection of one causing the other section to be grayed out. This puts all the control in the users hands.
------------------------------------------------
[x] Use settings from project configuration
[text box with path to file, e.g. com.foo/pom.xml]
------------------------------------------------
[ ] Manually associate repository
[x] Eclipse Bugzilla
[ ] Edgewall Trac
Eugene: are you or someone else from Maven interested in contributing this?
I thing it should be much simpler and the idea is to avoid manual configuration if possible. So, we can just have priority value to came from the extension point (can be configurable from global properties). Then project properties ui would still show mapped project, but may also disable the editing if extension point contributor prohibits editing. Then Mylar can just iterate trough contributed extensions in proper order. I.e. JIRA, Maven, Manual. I can try to shape up this for Subclipse and Maven plugins if you are okay with the approach. The final control needs to be in the user's hands, not in the extension points. When tools think they know better than users, some users invariably end up frustrated. So I'm happy with the approach the you propose, just don't allow the extension point to disallow editing. (In reply to comment #9) > The final control needs to be in the user's hands, not in the extension points. > When tools think they know better than users, some users invariably end up > frustrated. So I'm happy with the approach the you propose, just don't allow > the extension point to disallow editing. It will be in the user hands. For Maven they will need to edit Maven's pom.xml and for JIRA - set issue tracking property. I am not sure if we can use Mylar's UI to make these changes and that is why I am suggesting to disable UI for manual editing if extension point has its own information. We can have an "overwrite" option that would fall back to the manual editing (if you insist), but I think that defaults still should be controlled by the extension points. This is somehow similar how code completion is handled in the Java editor. Maybe we can provide global settings to allow user to enable/disable these extension points or change their order, but I think it is an overkill. OK, let's go for what you suggest, and then if in the final implementation the lack of control on the UI level seems problematic we can address it then. Created attachment 59419 [details]
implementation of new extension point
Current code for manual repository linking is movedin to DefaultTaskRepositoryLinkProvider which is registered as a default extension point.
<extension
point="org.eclipse.mylar.tasks.ui.repositoryLinkProviders">
<linkProvider
class="org.eclipse.mylar.tasks.ui.DefaultTaskRepositoryLinkProvider"
name="Default Repository Link"
order="1000"
id="org.eclipse.mylar.tasks.ui.defaultRepositoryLinkProvider">
</linkProvider>
</extension>
Provider implementation for Subclipse look like this and it is registered with order 100. So, editing is disabled in the Task Repository page if provider has link and does not allow to change it (technically it could, but it might be confusing because it will require commit to the version control, so I amy look at that later).
public class SubclipseTaskRepositoryLinkProvider extends
AbstractTaskRepositoryLinkProvider {
public TaskRepository getTaskRepository(IResource resource,
TaskRepositoryManager repositoryManager) {
try {
ProjectProperties props = ProjectProperties.getProjectProperties(resource);
return SubclipseTeamPlugin.getRepository(props.getUrl(), repositoryManager);
} catch (SVNException ex) {
// ignore
}
return null;
}
}
Provider for Maven will be abot that simple too.
Created attachment 59420 [details]
mylar/context/zip
"Provider" can be a redundant name so I try to avoid it if there is another name that's clear enough, but I can't think of anything better. However, I think that the name should say that the thing being linked is the project, because the repository aspect seems implicit from the fact that it's tasks.ui. What do you think of:
<extension
point="org.eclipse.mylar.tasks.ui.projectLinkProviders">
<linkProvider
class="org.eclipse.mylar.tasks.ui.ProjectPreferencesLinkProvider"/>
</extension>
Side note: at some point I might move this and other org.eclipse.core.resources coupling out of ..mylar.tasks.ui because they prevents the Task List from being reused in a pure RCP app.
(In reply to comment #14) > "Provider" can be a redundant name so I try to avoid it if there is another > name that's clear enough, but I can't think of anything better. However, I > think that the name should say that the thing being linked is the project, > because the repository aspect seems implicit from the fact that it's tasks.ui. > What do you think of: > > <extension > point="org.eclipse.mylar.tasks.ui.projectLinkProviders"> > <linkProvider > > class="org.eclipse.mylar.tasks.ui.ProjectPreferencesLinkProvider"/> > </extension> That is ok with me. Either way it is little confusing (link is currently one way from the project/resource to the repository). So, will you rename those yourself? Patch looks good. Please do the rename and I'll apply. In the future please do consider adding a unit test for this kind of functionality, at least to make sure that the default provider was initialized and has some default behavior. Created attachment 59443 [details]
updated patch
Patch applied. (In reply to comment #18) > Patch applied. Thanks a lot Mik. Can you please put new dev build? So, I could commit changes to Subclipse and Maven. Now I am thinking how we can reuse this info for creating new/missing repositories that are not added in Mylar yet. I added some doco at http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Mapping_from_projects_to_Task_Repositories Good stuff. Dev build uploaded. Regarding automatic creation consider commenting on bug 159135. (In reply to comment #21) > Good stuff. Dev build uploaded. Regarding automatic creation consider > commenting on bug 159135. Umm. Which bug? Sorry, bug 174864. |