Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.0.14) Gecko/2009082706 Firefox/3.0.14 GTB5 Build Identifier: If you hit this button in Task Editor whole metadata for the current repository is refreshed. I think we could improve it and refresh only metadata needed to properly render content of the editor/current task. This would decrease time user has to wait until she can edit the task again. Also I think it would be more intuitive. Reproducible: Always
Created attachment 148100 [details] Fix Here's a fix that extends Mylyn API to allow conector to have a refresh task configuration ability. It doesn't break existing plugins (only adds new methods with a proper defaults). This patch includes also a fix for 255430 - as they would conflict if tried to apply both of them. Also include a fix for JIRA that uses the new API which results in refreshing only the selected project attributes after clicking "Refresh Details" in task editor.
Created attachment 148101 [details] mylyn/context/zip
That looks good Pawel. I have added the necessary API as part of 273469. Can you update your patch to reflect the changes? You will probably need to store the projectId on ITask in JiraRepositoryConnector.updateTaskFromTaskData(). Note that this will currently only work if tasks are updated or new tasks are created. I have created bug 290604 to address that limitation. Does your patch include the changes for bug 255430? If not, it would be great if you could include them. Instead of using Policy.subMonitorFor() or SubProgressMonitor() I would prefer SubMonitor.convert() which is simpler and more flexible while providing more accurate feedback in most cases.
Created attachment 148231 [details] Patch with the new API and SubMonitor Here's a new patch (includes fix for 273469 too). Using ITask and updateTaskFromTaskData, attaching new IJiraConstants.ATTRIBUTE_PROJECT_ID to the ITask. Using SubMonitor to track progress for refresh details job. BTW Policy.subMonitorFor is not widely used in Mylyn so Steffen may be it should be depracated? As you said it's better to use SubMonitor.convert. Looking forward for feedback. Cheers, Pawel
Created attachment 148232 [details] mylyn/context/zip
Created attachment 148292 [details] updated patch
Looks great. I have tweaked the progress reporting in the attached patch a bit more and reused JiraAttribute.PROJECT.id() instead of adding a new constant IJiraConstants.ATTRIBUTE_PROJECT_ID. If you add a test case for JiraClientCache.refreshProjectDetails() I'll merge the patch. > BTW Policy.subMonitorFor is not widely used in Mylyn so Steffen may be it > should be depracated? As you said it's better to use SubMonitor.convert. Good idea. I'll do that.
BTW has anyone configured JIRA 4.0 test instance? I see most of the tests are failing for it?
Created attachment 148317 [details] Patch with test Added new JiraClientCacheTest, using a mock here. Also improved progress indicator a little bit - using SUPPRESS_NONE in additional places makes progress monitor to be more informative. Cheers, Pawel
Created attachment 148318 [details] mylyn/context/zip
(In reply to comment #8) > BTW has anyone configured JIRA 4.0 test instance? I see most of the tests are > failing for it? Afaik we can only run one instance at a time (due to server resources), so the 4.0.0 instance is not running. Some tests might pass because they do not need the server.
Thanks Pawel! I have applied the patch. We'll look into setting up a public JIRA 4.0 server for testing again as part of bug 290202 but as Thomas has mentioned our Eclipse vserver may not have sufficient resources to run multiple instances of JIRA. If that turns out to be the case I'll add a magic flag to enable JIRA 4.0 tests so they won't run by default and cause the suite to fail.
Seems like both Jira 3.13 and Jira 4 running take up 2/3 of the memory we got at our disposal...
