Community
Participate
Working Groups
In my company we run into a problem when trying to adopt mylar. Several developers had the same project checked out in their workspaces with different project names. When one developer tried to retrieve the context of a task that was created by another developer it was completely useless because the project names were different and mylar was unable to find the relevant resources. We thought that by renaming the project the task context would get updated but it doesn't. So, i wish mylar was able to update the context files when the projects are renamed. Could this be also true for method and classes? Is mylar listening to refactoring events to appropriately update the context?
Yes, we have this problem too, and so sometimes oure contexts 'miss' this information. Our current idea is to use the refactoring history (project -> Properties -> Refactoring History) to support this. I assume that it is possible for your team to enable the setting to store the refactoring history in the project folder?
Why do you say "after refactoring outside of workspace"?? When i say "renamed the project" i mean refactored the name of the project inside the workspace and the context did not get refactored.
I think what Erick wants is to make the context contents participate on refactorings, via refactoring participant extension point. Right?
Sorry, I misunderstood. I created bug 164243 for the problem described in comment#1. Regarding this problem, I created the following FAQ entry: http://wiki.eclipse.org/index.php/Mylar_FAQ#Why_is_interest_lost_when_I_retrieve_someone_else.27s_context.3F The problem is that we rely on the project's name to determine the project's identity, as that is the simplest approach that works across local projects and those managed by different team providers. The current work-around is to standardize on the project names when sharing context. Please vote for this bug if that approach does not work for you.
Relyimg in the project name is not a bad thing. Unless there is a different way to guarantee context validity across workspaces, this seems pretty reasonable. What I meant, as William said, is to have the task context participate in rafactorings.
Another issue related to the lack of refactoring participation that I got today: - Synchronize your project with automatic change sets management on. - Execute the move refactoring on a changed file. - After that, the file will lost its degree of interest and will get out the change set. Workaround: - Drop the synchronization. - Mark the refactored resources as mylar landmark to force interest. - Re-synchronize. However, there is a bug here: the refactored resource will not appear in the change set, neither on the other change sets (including the "no change set"), but if you make a patch it will appear there. I haven't tried, but I think that if in this case you try to commit the change set, the missing file will be commited together. I think so, because I saw this type of bug to happen many types, and now it finally appears to be a reproducible case.
Willian: some of the problem you describe in comment#6 is fixed by better resource delta management. We already participate in some refactorings, but should do this consistently across all to avoid problems like those described here. Will schedule post 1.0.
*** Bug 191867 has been marked as a duplicate of this bug. ***
Will consider this for 3.0. It's important for preserving the fidelity of the context model.
Does this bug address the problem outlined in the following conversation? From: Jörg Thönnes [mailto:Joerg.Thoennes@macd.com] Sent: Wednesday, March 26, 2008 11:55 AM To: Curtis, Steven Subject: Re: Large refactoring On 03/26/08 15:24, Steven Curtis wrote: > I have a large refactoring job in which a commonly used file is being > moved from one package to another. With a task activated, Refactor -> > Move completes the job be modifying more than 70 files, but only the > file being moved is added to the task context. Why aren't the other 70 > files added as well? Am I missing something? AFAIK the refactoring events are not handled by Mylyn at the moment. Even if I move a single file the context lacks the methods/classes acccessed in the old file. There is a related bug in the Eclipse Bugzilla, this should be planned for 3.0. Please look for the bug and vote on it. Thanks, Jörg
Hi Mik., you decreased the priority to P4 (enhancement). Personally, I consider this as a notable restriction on Mylyns context tracking and do hope that this will be part of the 3.0 release. Thanks, Jörg
(In reply to comment #10) > Does this bug address the problem outlined in the following conversation? > From reading previous posts, the answer is yes. Thank you for paying no attention to my comment. I should read more.
Jörg: I would really like to get to this for 3.0, but made it a P4 because it is a very involved change that would come at the sacrifice of the API improvements that we have prioritized for 3.0.
(In reply to comment #13) > Jörg: I would really like to get to this for 3.0, but made it a P4 because it is > a very involved change that would come at the sacrifice of the API improvements > that we have prioritized for 3.0. OK, understood. So I continue to use my "normal" time tracker and use the Mylyn time tracking just for sanity checking. It is quite clear to me that the API improvements lay the base for any new things to come. Hopefully, there will also be a (better) API for time tracking support.
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
*** Bug 112721 has been marked as a duplicate of this bug. ***
*** Bug 344166 has been marked as a duplicate of this bug. ***
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
