Community
Participate
Working Groups
JIRA project keys are unique enough to be able to autodetect repository from the issue id.
Created attachment 57176 [details] path for Open Corresponding Task action This patch iterates trough all connectors for all repositories to check if there is matching task id. That works very nice for JIRA ids.
Created attachment 57177 [details] mylar/context/zip
Patch applied and looks good, but I leave the verification to you. Note that while it's not currently our convention, I've been avoiding using labels and breaks because I find that they often make code harder to read (e.g. if the body of the loop grows or other labels are added) and because I find that they take a small step away from structured programming. I realize that sometimes it's the most concise way of stating something, but even in cases like this I find it more obvious to have a boolean flag of foundRepository. I realize that this convention is not in the Java Code Conventions that we adhere to, so I'm thinking of adding it. Thoughts?
(In reply to comment #3) > Patch applied and looks good, but I leave the verification to you. Can we have another dev build then? > Note that while it's not currently our convention, I've been avoiding using > labels and breaks because I find that they often make code harder to read (e.g. > if the body of the loop grows or other labels are added) and because I find > that they take a small step away from structured programming. I realize that > sometimes it's the most concise way of stating something, but even in cases > like this I find it more obvious to have a boolean flag of foundRepository. I > realize that this convention is not in the Java Code Conventions that we adhere > to, so I'm thinking of adding it. Thoughts? I thought that you would be more concerned with blind iterating trough all possible repositories. :-) As of "break" use, I found for myself that there is no nice way to quickly exit from two nested foreach loops. So, "break" was a tradeoff to avoid using for loop.
Yes, I do think we should consider the implementation strategy here, and added an item to the meeting agenda. Since the iteration over all repositories only happens when the user executes this action, it's not currently bad. But it could trigger a slow lookup on some repository, and is related to hyperlinking, so let's chat about this on the next call.
BTW, initially I was thinking to iterate only trough JIRa repositories and only do that in the getTaskIdsFromComment(), but that way it didn't allowed to find matching connector and repository that is needed for the Open Correspond Task action. So, I ended up iterating trough all repositories. We also have bug 170690 that should deal with these slow cases. 170690: OpenCorrespondingTaskAction should not run in the UI thread https://bugs.eclipse.org/bugs/show_bug.cgi?id=170690
