| Re: [mylyn-integrators] Help needed with Mylyn-API |
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
>