Re: [mylyn-integrators] Help needed with Mylyn-API

[Shawn Minto <sminto@xxxxxxxxx>]

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
sminto@xxxxxxxxx
----------------------------------------



On Mon, Jul 25, 2011 at 12:48 PM, Marc <my.mailing.lists@xxxxxx> 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 <sminto@xxxxxxxxx>:
>
>> 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
>> sminto@xxxxxxxxx
>> ----------------------------------------
>>
>>
>>
>> On Tue, Jul 19, 2011 at 3:01 PM, Marc <my.mailing.lists@xxxxxx> 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
> mylyn-integrators@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>