Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-integrators] Help needed with Mylyn-API

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,
> and migrate the context when given a mapping.
>
> *My problem resides within MigrationContext.migrateTaskContext.*
> Whatever I do, the context is updated at runtime, and a the file storing the
> tasks information is also updated (according to the change-column), but it
> always contains the old history. As it seems by now, the API is only writing
> the Interaction-History of a element to the filesystem, not the whole
> context, and by changing the HandleIdentifier manually no Interaction-Event
> occurs
> As you can see in the commented lines I did try quite some other calls
> (internal API as well which I wanted to avoid in the first place). Currently
> I think the only solution that might work is manipulateInterestForElement in
> line 71...but I couldnt figure out how to use it in the correct way.
>
> Another attempt is also "shipped" in the archive: in the class
> ContextMigrationBean2 I tried to utilize the ContextListener which kinda
> worked but this way I always have to activate and deactivate a task and its
> not a clean migration since the old history is also still there.
>
> I am really hoping that someone can come up with an idea...
>
> Thanks in advance
> Marc
>
>
> Am 12.07.2011, 03:30 Uhr, schrieb Shawn Minto <sminto@xxxxxxxxx>:
>
>> Hi Marc,
>>
>> It seems that there should be a way to get your current approach to work
>> using the context framework. World you be able to share a sample of what
>> API
>> and algorithm you were using along with any more details about the failure
>> so that I can help you track down the right method to migrating contexts
>> this way.
>>
>> It would be great to see your results and see if there is some way that we
>> could make this support available to others as I agree that this could be
>> useful for other developers as well!
>>
>> Shawn
>>
>> --
>> Shawn Minto
>> sminto@xxxxxxxxx
>> ----------------------------------------
>>
>> On Fri, Jul 1, 2011 at 2:35 PM, Marc <my.mailing.lists@xxxxxx> wrote:
>>>
>>> Hello everyone
>>>
>>> I am new to this list and I hope somebody can help me with my problem, or
>>
>> at
>>>
>>> least enlighten me ;)
>>>
>>> Here is what I am trying to accomplish:
>>> At my current project I am advocating Mylyn to my collegues...I skip the
>>> details, you all know the benefits of Mylyn.
>>>
>>> Anyway, we have one problem. Every four month we are branching the
>>> source-code and when this happens I am loosing my Context. Ok, the
>>> Context
>>> is still there, but no files can be opened because with the branching the
>>> projectname also changes and Mylyn uses the projectname to identify
>>> resources in its handleIdentifiers. For the record, we HAVE to change the
>>> projectname due to filter-tokens that are hard-coded and specific for
>>> each
>>> branch...yes its a legacy monolithic spagetti-code project ;)
>>>
>>> Hence, I got the idea of writing a plugin which can migrate a Context to
>>> other projects. My plugin extracts all occuring projects from the
>>> handleIdentifiers and provides a dialog to map those to existing
>>> workspace
>>> projects. Afterwards the handleIdentifiers are replaced by the correct
>>> mapping.
>>> *And here comes the problem: After saving the context, none of my changes
>>> are persisted!*
>>> I realised that I am obviously using the API in an non-expected way and
>>
>> that
>>>
>>> a context only changes when an interaction with a resource occurs (using
>>
>> the
>>>
>>> bridges). But in my case there is no such interaction.
>>>
>>> Another way I found was to register a ActivationListener and hook into
>>> the
>>> PRE_ACTIVATION-phase where I can set the handleIndentifier as well but I
>>> dont think this is a good approach and furthermore I have the problem
>>> that
>>
>> I
>>>
>>> need to activate a task which is bad when multiple contexts should be
>>> migrated.
>>>
>>> The last idea I found was to process an InteractionEvent. But to do this
>>> I
>>> need to get the actual eclipse-resource (correct me if I am wrong), which
>>
>> I
>>>
>>> currently cannot get a hold on from the handleIdentifier. The downside
>>
>> here
>>>
>>> is as well that the context needs to be activated. The code I was trying
>>
>> to
>>>
>>> use looks like this:
>>>
>>> ContextCorePlugin.getContextManager().processInteractionEvent(<element
>>
>> goes
>>>
>>> here>,
>>>       InteractionEvent.Kind.PROPAGATION, InteractionEvent.ID_UNKNOWN,
>>> context);
>>>
>>>
>>>
>>> Until now I've spent a lot of time investigating the API but I am not
>>> getting any further. In the beginning I tried not to use internal classes
>>> but as it looks now I cannot accomplish what I am trying by just using
>>> public API.
>>> *So I am asking here to find some advice how to approach this. Can anyone
>>> help my in this case?*
>>>
>>>
>>> best regards
>>> Marc
>>>
>>>
>>> P.S. I was thinking of publishing my result back to Mylyn but after my
>>
>> first
>>>
>>> idea didnt work the code doest look so nice right now ;) But I am quite
>>
>> sure
>>>
>>> that this feature would be useful to others as well.
>>> _______________________________________________
>>> mylyn-integrators mailing list
>>> mylyn-integrators@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
>>>
>
>
> --
> 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
>


Back to the top