Community
Participate
Working Groups
From bug 169426 comment 25: For cloning of task data a new method should be added to AbstractTaskDataHandler. A default implementation could clone the common attributes: summary, description and possibly iterate over editable attributes of the source task data and the new task data. The latter is probably only feasible if both task data objects are associated with the same repository. Connectors can overwrite that method and provide a more specific implementation if needed.
Created attachment 82625 [details] implementation of cloneTaskData
Created attachment 82626 [details] mylyn/context/zip
(In reply to comment #1) > Created an attachment (id=82625) > implementation of cloneTaskData I think AbstractTaskDataHandler.cloneTaskData should be called from performFinish of the New<RepositoryTyp>TaskWizard (NewBugzillaTaskWizard, NewJiraTaskWizard, ...). How we can get the information from the action to the New<RepositoryTyp>TaskWizard. What do you think about this. - Create of a class that can hold the information of the sourceTaskData. This can be used for other cases like comments, stacktrace, ... - this class should be passed to the wizard so that we can pass it to connectorUi.getNewTaskWizard and then to New<RepositoryTyp>TaskWizard But this meens that AbstractRepositoryConnectorUi must be changed. This meen that all Connectors need to be modified. What is the best way to do this.
(In reply to comment #3) > > But this meens that AbstractRepositoryConnectorUi must be changed. This meen > that all Connectors need to be modified. > Should we define an Interface which we can add to the subclasses of AbstractRepositoryConnectorUi. Then in NewTaskPage we can test if the new method is defined and use it so that we can reate the correct version of New<RepositoryType>TaskWizard Should I try this way?
Created attachment 82716 [details] test implementation This is a test of the new way. I create CloneTaskAction as an example to demo that this works. Do you think this is the right way? If so we can extend NewTaskWizardSeletion to handel the other cases.
Created attachment 82717 [details] mylyn/context/zip
The patch is looking good so far. Let's focus on adding the new API to TaskDataHandler first before implementing the wizard. Most important are JUnit test cases that verify the implementation of the clone method using task data objects (see http://wiki.eclipse.org/Mylyn_Contributor_Reference#Writing_Tests). I think the signature of the clone method should look like this: public void cloneTaskData(RepositoryTaskData sourceTaskData, RepositoryTaskData targetTaskData); A list of attributes to ignore would be connector specific and difficult to specifiy for a caller. How about making the default implemenation only clone attributes that exist on the source as well as on the target task data? In case connectors need to ignore certain attributes the default implementation should be overriden in the connector. It would be great if you could attach a patch that contains the changes to AbstractTaskDataHandler and test cases only. Once that is merged we can iterate further on implementing the wizard. Here are a few remarks from looking through the patch: - Please delete all comments before attaching a patch to ease the reviewing process. If there are open questions about the implementation it is better to discuss on the bug before attaching a patch. - I like idea of having the NewTaskWizardSeletion class that encapsulates the task selection. You could rename it to TaskSelection and it should be immutable. - The default implementation of the new getNewTaskWizard() method in AbstractRepositoryConnectorUi should invoke the old method ignoring the selection and getNewTaskWizardType() is not needed. That way NewTaskWizard can always invoke the new method and the old method can be marked as deprecated and removed in the 3.0 release. - The TaskSelection object could only be passed to NewTaskWizard and NewTaskPage for now instead of modifying SelectRepositoryPage which is used in many other places as well that don't require the selection.
What is the relation to bug 161646: [patch] Support for Clone this bug There you can cascade a bug to another (kind of) repository with a back reference. The copying of data can be more elaborate, is that done here?
Once this bug is completed the implementation can be shared with bug 161646 and in addition the back link can be added. Let's finish this bug first and then look at refining the patch for bug 161646.
Created attachment 82920 [details] Patch with jUnit Test create JUnit tests for bugzilla taskData. Not all attributes on an bug are tested. Here the list of attributes currently not included. assigned_to_name, reporter_name, qa_contact, new_comment, resolution, everconfirmed, actual_time=actual_time, newcc=newcc, bug_file_loc, reporter_accessibl, cc, blocked, keywords, longdesclength, status_whiteboard, cclist_accessible, classification_id, dependson Should I include these attributes ? Should I do an test for the other connectors?
Created attachment 82921 [details] mylyn/context/zip
(In reply to comment #9) > Once this bug is completed the implementation can be shared with bug 161646 and > in addition the back link can be added. Let's finish this bug first and then > look at refining the patch for bug 161646. Same for bug 152869 and bug 169426.
I was wondering if it would make sense that the attributes that can't be mapped are appended to the description? I think that this is useful since it is easier to delete a chunk of text over trying to merge some information from the old task to the new one.
Shawn, that sounds like a great idea. There is some pending work for having a textual representation of differences between task data on bug 205861. We should be able to reuse some of that code once we are done here.
I have committed the patch with modifications. The default implementation clones all attributes if the source and target task data task and repository kinds match. In other cases it will only clone a selected set of attributes that have keys defined in RepositoryTaskAttribute. Rob, please review the Bugzilla specific test case. I haven't applied it, yet.
Created attachment 82930 [details] mylyn/context/zip
(In reply to comment #15) > Rob, please review the Bugzilla specific test case. I haven't applied it, yet. Test portion of patch applied.
