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 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/


Back to the top