Community
Participate
Working Groups
Many connectors have no special support for comment replys but each connector has to implement @AbstractRepositoryConnector#getReplyText@. We should think about pulling up the Bugzilla implementation. This way 90% of connectors can save implementing this while the other 10% still have the ability to override it.
The assumption was that the format would differ considerably between connectors and hence no default implementation was provided. If that's not the case we should pull up the Bugzilla implementation as suggested. Benjamin, I'll tentatively assign to you.
From the connectors I checked (some open source eg. GitHub and several commercials), all of them either have an exact copy of the Bugzilla implementation or implement it to return pretty much the same message. Oddly, some of them (eg. GitHub) completely forgot to implement it (happend to me too) and thus are missing this functionality. I still see potential to override it but a default implementation would help a lot of connectors.
Review at https://git.eclipse.org/r/#/c/6307/ Two open discussion points: * I think we should use "(In reply to description)" when replying to the description * The parameter @includeTask@ is never used by the framework. Should we maybe deprecate the current method and introduce a new one without that param?
Created attachment 217122 [details] mylyn/context/zip
Looks good to me! Can you assert the usual IP blurb on the review? (In reply to comment #3) > Review at https://git.eclipse.org/r/#/c/6307/ > > Two open discussion points: > * I think we should use "(In reply to description)" when replying to the > description This could make sense but would require a custom implementation for Bugzilla. To properly implement that we should have an API for retrieving the link text for a comment or the description but I would leave that for later. > * The parameter @includeTask@ is never used by the framework. Should we maybe > deprecate the current method and introduce a new one without that param? That makes sense but I'm wondering if it's worth the trouble. I'd rather do that for 4.0 when we can break API. We could add a comment that the parameter is not used.
The changes were merged into master. Thanks very much for the contribution!
Thanks Steffen!
