Bug 409758 - [api] allow clients to determine the first and last activity dates of a task
Summary: [api] allow clients to determine the first and last activity dates of a task
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: 3.10   Edit
Assignee: Lily Guo CLA
QA Contact:
URL:
Whiteboard: sprint=3;effort=1;
Keywords: contributed, noteworthy
Depends on:
Blocks:
 
Reported: 2013-06-03 12:40 EDT by Sam Davis CLA
Modified: 2013-11-04 14:46 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Davis CLA 2013-06-03 12:40:32 EDT
Clients can get the active time for a task between any two dates, but there is no way to determine the first and last activity dates of a task. To better support reporting over time tracking data, we should allow clients to determine the first and last activity dates of a task.
Comment 1 Lily Guo CLA 2013-06-03 17:07:48 EDT
I've made a patch: https://git.eclipse.org/r/#/c/13249/
Comment 2 Sam Davis CLA 2013-06-19 16:22:36 EDT
Thanks very much for the contribution!
Comment 3 Steffen Pingel CLA 2013-06-19 17:28:27 EDT
Sam, it's helpful to set the contributed keyword for bugs resolved by non committers. That we can count these bugs and give credit more easily. Great to see this go in!
Comment 4 Steffen Pingel CLA 2013-06-24 11:13:39 EDT
I'm reopening since the change caused API breakage. We'll need to discuss whether to annotate ITaskActivityManager as @noextend or revert the API change.
Comment 5 Sam Davis CLA 2013-06-26 14:19:17 EDT
Steffen, I'm not sure I understand your comment. We knew this would cause API breakage which is why I asked you about it. It may make sense to add @noextend (and @noimplement?) so that we don't have to worry about breaking the API anymore, but the previous API would still be broken.
Comment 6 Steffen Pingel CLA 2013-06-26 14:36:56 EDT
Sorry, that was my misunderstanding. I thought the question was just if it made sense to expose this as API rather than breaking binary backwards compatibility. 

My view is that not adding @noextend and @noimplement was an oversight to begin with. If we add methods to the interface or add the annotations now this will break API and we would have to create filters for the errors and document it in the porting guide.

The alternative is to remove the new methods from the interface and ask clients to access the implementation class or to create an ITaskActivityManager2 interface.

I don't know if there are any clients outside of Mylyn implementing the interface (and for whatever reason that would make sense) so I wouldn't object to adding the annotations and filters and leaving the implementation as is. On other hand, if the consumer of the API would be okay accessing internals this would be less risky in terms of breaking existing integrations.
Comment 7 Sam Davis CLA 2013-06-26 16:49:10 EDT
How about we create an ITaskActivityManager2 interface, mark it as @noextend and @noimplement, and add the new methods there? That way we don't break API and we don't force clients to access internals, and we'll be able to continue to add to that interface if needed.
Comment 8 Steffen Pingel CLA 2013-06-26 17:38:59 EDT
(In reply to comment #7)
> How about we create an ITaskActivityManager2 interface, mark it as @noextend and
> @noimplement, and add the new methods there? That way we don't break API and we
> don't force clients to access internals, and we'll be able to continue to add to
> that interface if needed.

Works for me.
Comment 9 Sam Davis CLA 2013-06-26 20:30:50 EDT
Great. Lily, can you make the change described in comment 7? ITaskActivityManager2 should extend ITaskActivityManager.
Comment 10 Sam Davis CLA 2013-06-27 20:09:13 EDT
I've merged https://git.eclipse.org/r/#/c/14128/2. Thanks Lily.