Bugzilla – Full Text Bug Listing
| Summary: | task repository linking for Eclipse.org projects via Bundle-Vendor or provider specification | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> | ||||||||||||||
| Component: | Mylyn | Assignee: | Eugene Kuleshov <ekuleshov> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | minor | ||||||||||||||||
| Priority: | P4 | CC: | b.muskalla, mik.kersten, steffen.pingel | ||||||||||||||
| Version: | unspecified | ||||||||||||||||
| Target Milestone: | 3.1 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Eugene Kuleshov
Created attachment 86061 [details]
repository link provider prototype
Here is the complete working prototype for described idea implementing link provider extension point in mylyn.pde.ui plugin (have to add mylyn.tasks.ui as dependency to mylyn.pde.ui).
Created attachment 86062 [details]
mylyn/context/zip
I'm not opposed to this approach off-hand, but have some concerns that it is a more brittle substitute for creating an explicit association as per bug 150278 (scheduled for 3.0). For example, last time that I checked (~1 year ago) Eclipse did not specify a format for setting the provider, and this could change. However, many Ganymede projects do consistently use "Eclipse.org", and this implementation could be a reasonable fall-back even if we did have an association specified. Steffen: thoughts? Eugene: to proceed with this for the 3.0 timeframe we would need you to take the bug over and commit to creating proper test coverage for it--i.e. programmatically creating a PDE project, setting its provider, creating a resource, then checking its linking. Our test suite has a bunch of code for programmatic project creation of this sort that we can point you at. (In reply to comment #3) > I'm not opposed to this approach off-hand, but have some concerns that it is a > more brittle substitute for creating an explicit association as per bug 150278 > (scheduled for 3.0). I would say it is a less intrusive substitute then the extension point. Besides, it is unclear what benefits extension point gives over storing it under .settings in the development environment. I could see how it could be used at the runtime, but even then there are less OSGi-specific alternatives available. > Eugene: to proceed with this for the 3.0 timeframe we would need you to take > the bug over and commit to creating proper test coverage for it--i.e. > programmatically creating a PDE project, setting its provider, creating a > resource, then checking its linking. Our test suite has a bunch of code for > programmatic project creation of this sort that we can point you at. I can certainly look at that, so please do give pointers. It's an interesting approach. As far as I understand bug 150278 the goal of the extension point is to improve error reporting during runtime by linking plug-in (ids) to task repositories whereas this report aims to improve linking between resources and task repositories to support developers. Any reason not to follow both approaches? Could we test drive this feature in the sandbox and migrate it to head once it has matured and proven to be useful? I think that the major advantage of this approach that it requires zero configuration and reusing already existing metadata which is reasonably consistent across many Eclipse projects as Mik already pointed out. So the feature is mostly useful to developers working on Eclipse.org projects, but it is unclear how one could prove its usefulness. Generally, I also suspect that many developers are not completely aware of Mylyn's project linking features and probably don't mind to do few additional clicks when creating new tasks or rarely create new tasks not from the Task List view, i.e. using Alt-Shift-N shortcut, that is when proposed feature come handy. That can be even less critical for them if Eclipse.org Bugzilla is the only issue tracking repository they have. Another use case is the automatic hyperlinking, though Platform is currently using the full urls to link Bugzilla issues. Since this mechanism is based on a String matching that's not well specified for Eclipse.org I want us to consider it a fall-back at least until that changes. However, I'm for going ahead with this since I agree that it should not get in the way of other mechanisms that we can provide for mapping task repositories. Since this is an Eclipse.org specific feature, the best home for it for now is org.eclipse.mylyn.bugzilla.ide, since that's the only plug-in that we have with Eclipse.org specific content (e.g. the bugs.eclispe.org template). If there is a dependency problem let me know since it might make sense to create a new plug-in that's specific to Eclipse.org and I've wanted to do that in the past. (In reply to comment #4) > > Eugene: to proceed with this for the 3.0 timeframe we would need you to take > > the bug over and commit to creating proper test coverage for it--i.e. > > programmatically creating a PDE project, setting its provider, creating a > > resource, then checking its linking. Our test suite has a bunch of code for > > programmatic project creation of this sort that we can point you at. > > I can certainly look at that, so please do give pointers. See how AbstractJavaContextTest.setUp() programatically creates a project and then tearDown() deletes it, and note usages of ResourceTestUtil (see attached context). You will need to do the same thing for a PDE project. (In reply to comment #7) > Since this is an Eclipse.org specific feature, the best home for it for now is > org.eclipse.mylyn.bugzilla.ide, since that's the only plug-in that we have with > Eclipse.org specific content (e.g. the bugs.eclispe.org template). If there is > a dependency problem let me know since it might make sense to create a new > plug-in that's specific to Eclipse.org and I've wanted to do that in the past. Mik, this feature require dependency on the following bundles: org.eclipse.core.runtime, org.eclipse.core.resources, org.eclipse.pde.core Are those acceptable for the bugzilla.ide feature? Especially the last one. Also, can you please clarify which bundle I should put test for this link provider. Created attachment 87597 [details]
updated patch wit hthe test case
Here is updated patch including test case. I put test case under mylyn.java.tests and left link provider in mylyn.pde.ui project due to concerns from the previous comment. Please let me know if things need to be moved around.
Created attachment 87598 [details]
mylyn/context/zip
I will review for 2.3, hopefully early next week. Those dependencies are probably OK, it's just ..mylyn.bugzilla.ide that's in need of refactoring. This is related to Steffen's efforts on bug 212209 and we plan on getting to it early in the 3.0 cycle. Steffen: please take a first pass at review. We also need to refactor ..mylyn.bugzilla.ide during or after considering this in order to make the dependencies reasonable. Can someone clarify if there is anything wrong with proposed patch or what is the overall plan in regards to this issue? Proposed implementation is using old repository linking API available in Mylyn 2.0, so unless there is a plan to change that API for 2.0, this issue isn't much related to bug 212209. I added a discussion about this to today's call agenda. I really like this idea! +1 from me Any update on this? I won't get to this for 3.0. Need to defer to 3.1. Can some else look at this? This is very useful feature that allows to eliminate need to manually link gazilinons of Eclipse projects/bundles with eclipse.org Bugzilla. Patch with corresponding tests been sitting there for several months and it is still unclear what is stopping Mylyn team from applying it. We're just to busy with API, testing and hardening to handle most enhancements right now, and the users who benefit from this will be able to consume it via update site after 3.0 goes out. I'll raise the priority to make sure we get to it early since there isn't much work left. Since the link provider proposed in the patch is Eclipse specific the pde.ui plug-in does not seem to be the right place for it. The bugzilla.ide plug-in would be a better match but that should not depend on PDE. Mik, how about putting it into the sandbox? I could not apply the patch since it references a class PdeProject that I can not find in the code base or patch. Eugene, I will apply the patch if you recreate it against cvs head of the Mylyn sandbox. Created attachment 116385 [details]
PdeProject code
Here is the class been asked for
Created attachment 116386 [details]
updated patch
Thanks Eugene! Patch applied to sandbox. The link provider will be available in the UI Experiments feature with the next 3.1.0 weekly build. Need to investigate this Exception: java.lang.NullPointerException at org.eclipse.mylyn.internal.sandbox.ui.EclipseTaskRepositoryLinkProvider.getTaskRepository(EclipseTaskRepositoryLinkProvider.java:57) at org.eclipse.mylyn.internal.sandbox.ui.EclipseTaskRepositoryLinkProvider.getTaskRepository(EclipseTaskRepositoryLinkProvider.java:42) at org.eclipse.mylyn.internal.tasks.ui.TasksUiPlugin$11.run(TasksUiPlugin.java:1178) [...] Added test case and fixed NPE. The repository linking provider logs the following error when trying to access a closed project: Resource '/project' is not open. Added check to link provider if resource is accessible. |