Hi Marc, As for looking up the project name, I think that what you have done is a good approach if you limit it to resource, java, c++ structure kinds. The one thing that I noticed is that the project handle was not refactored correctly. I didn't look at the code, but I assume that it was due to the regex expecting a trailing slash but since it is the project, that doesn't exist.
Shawn -- Shawn Minto [email protected] ---------------------------------------- On Mon, Jul 25, 2011 at 12:48 PM, Marc <[email protected]> wrote: > Hi Shawn > > This is more than I've expected at all :) ... thanks a lot. > I had a look at your proof of concept and it looks quite straight forward. I > realized that the history wasnt updated but I only tried to use API-methods > to make it work. I will try to create a patched context.core plugin the next > days. > > I've got one more question: > You mentioned that the way I look up the projectname is not absolutely save. > Do you have any recommendation? I know that my approach will break for other > resource types than Java and Standard but I couldnt find any better solution > than a regex. > > Thanks again for your great help...hope that the patch will be included in > an official Mylyn-Release. > Marc > > > Am 22.07.2011, 22:32 Uhr, schrieb Shawn Minto <[email protected]>: > >> Hi Marc, >> >> Sorry for being slow with this as well. >> >> Thanks for posting the code and the great explanation of everything. >> I did some investigation and it seems that the method to update the >> handle doesn't do everything that is needed (i.e. it should work for >> the active context, but the changes will not be stored). The problem >> is that with this type of handle refactoring, the entire >> InteractionEvent history needs to be changed as well. I was able to >> make it work with some changes to the context framework. I have >> created the following bug to make these changes: >> >> 352911: support refactoring handles within a context >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=352911 >> >> As for the code that you posted (to run with this patch), here is >> what the method in question looks like that mostly works (note that >> there are some handles not migrated due to the way that you look up >> the project name): >> >> public void migrateTaskContext(Map<String, String> mappings) { >> for (MigrationCacheElement element : elementCache) { >> String currentProjectName = >> element.getCurrentProjectName(); >> String newProjectName = mappings.get(currentProjectName); >> >> String newHandleIdentifier = >> element.getInteractionElement() >> >> .getHandleIdentifier().replaceFirst(currentProjectName, newProjectName); >> >> >> context.updateElementHandle(element.getInteractionElement(), >> newHandleIdentifier); >> } >> >> LocalContextStore store = >> (LocalContextStore)ContextCore.getContextStore(); >> store.saveContext(context); >> } >> >> Shawn >> >> >> -- >> Shawn Minto >> [email protected] >> ---------------------------------------- >> >> >> >> On Tue, Jul 19, 2011 at 3:01 PM, Marc <[email protected]> wrote: >>> >>> Hi Shawn >>> >>> Thanks for your reply and sorry for my late answer...I wanted to clean up >>> my >>> code from all the messy testing I was doing :) >>> >>> Instead of posting tons of snippets which I think are hard to read on a >>> mailing-list I uploaded my whole project to a public wuala-share as a >>> ZIP-archive. I hope this is not offending anyone (for just dropping the >>> whole thing) but I am completely lost how to continue. >>> >>> https://www.wuala.com/lostiniceland/Public/?key=LqoLkqR6fBEj >>> >>> >>> The source contains all projects: >>> *custom.mylyn.extensions.core* - There the main logic is >>> implemented >>> *custom.mylyn.extensions.core.tests* - A test-fragment. Until now only >>> tests for the Regex that finds the projectnames. >>> *custom.mylyn.extensions.ui.view* - The view-part. It adds a >>> menu-item >>> to the contextmenu of a ITask "Migrate Context" and displays a Dialog for >>> the mapping. >>> *custom.mylyn.extensions.feature* - Just the feature-project >>> >>> I think a brief introduction how the plugin(s) work is useful (comments >>> on >>> design-flaws are welcome). >>> >>> 1. When one or more Tasks are selected in the Tasks-View the menu >>> >>> 2. A click will trigger the creation of a new ContextMigrationBean via a >>> Factory >>> >>> 3. The view asks the bean for a Set with all projectnames that occur >>> within >>> the contexts >>> >>> 4. The view presents a dialog where the found context-projectnames can be >>> mapped to existing workspace-projectnames and stores the result in a map >>> >>> 5. The method migrate on the ContextMigrationBean is called given the new >>> mappings >>> >>> >>> The main component in my approach is the class *MigrationContext* which >>> holds a reference to an IInteractionContext and is responsible for >>> retrieving and caching projectnames for each occuring >>> IInteractionElement, > > > -- > Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ > _______________________________________________ > mylyn-integrators mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/mylyn-integrators > _______________________________________________ mylyn-integrators mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
