Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 389544 - [api] Provide Review update API
Summary: [api] Provide Review update API
Status: CLOSED MOVED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 401472
  Show dependency tree
 
Reported: 2012-09-13 13:32 EDT by Miles Parker CLA
Modified: 2013-04-26 11:11 EDT (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 Miles Parker CLA 2012-09-13 13:32:55 EDT
The Mylyn approach to managing task (Review) state change is significantly different from the way that R4E manages such changes. Briefly, Mylyn changes are course-grained (Task Level) and essentially optimistic, while R4E model changes are fine-grained (to attribute level) and support pessimistic locking/check-out.
Definitions:

TaskRespository: R4E ReviewGroup
TaskRepositoryURL: Represents the location of a unique ReviewGroup. In the initial case, an EMF URI shared file system location.
Task: R4E Review
TaskID: A unique identifier for a Review within a specific ReviewGroup/Repository. This could be a UUID, user assigned or other appropriate value, but ideally it would be a simple human readable sequential ID.

For example:

TaskRepositoryURL: file:/Z:/R4EReviews//some_reviews.xrer
TaskRepositoryID: 123

On the Mylyn side, these are combined to form a unique task URL, e.g.: file:/Z:/R4EReviews//some_reviews.xrer/123, but we could use a different separator if desired. This would of course be different from the actual R4EReview EObject URI.

In order to support Mylyn Tasks, we need R4E API that accomplishes something like the following. Some of this API may already be in place in which case we just need to identify the appropriate calls. Ideally we'd access all of these calls from a single class API, e.g. R4EModelManager or whatever.. This is the basic functionality we need:

1. Pull/Update: Return an EObject for a given review based on a supplied TaskRepositoryURL and TaskID.
2. Push (New): Accept a complete new Review EObject, with a supplied TaskRepositoryURL and add it to the appropriate ReviewGroup. This method then must return or provide a new unique Task ID.
3. Submit/Update: Accepts a complete Review EObject, with a supplied TaskRepositoryURL and TaskID and merges it into the existing review group. The method returns an updated EObject and Status for result:
	If object could be merged, returns Status OK new (merged) object from shared store.
	If object could not be merged returns Status ERROR and (non-merged) object from shared store. 
	[optional] If object partially merged, returns Status WARNING and (partially-merged) object from shared store, perhaps with a multi-status indicating references/attributes that could not be merged.
Comment 1 Miles Parker CLA 2012-10-22 14:59:11 EDT
Wanted to check on status on this. This is going to be needed to get the integration for the R4E system working fully.
Comment 2 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn