Community
Participate
Working Groups
My scenario: Several projects access each others source folder not via project dependency but via source folders (as links). The reason for this is that a fair amount of code generation is involved and some projects need generated interfaces from another one, but no manually written code (just to provide reasons for this setup). We have come across several weird observations with the "Rename method" refactoring (others may also be affected): 1. Project Layout for two projects: "One" and "Two" (source folder="src", Project "One" contains package "one", "Two" contains "two") One src one ClassOne.java Two src two ClientOfClassOne.java src_one (link to source folder of project "One", also a source folder for this project) one.ClassOne will appear in project Two through the linked source folder "src_one". exampleCode: package one; public class ClassOne { public void aMethod() { return; } } package two; import one.ClassOne; public class ClientOfClassOne { ClientOfClassOne() { ClassOne reference = new ClassOne(); reference.aMethod(); } } ----- The result of renaming ClassOne.aMethod() to ClassOne.aRenamedMethod() differs depending on where it is done: Renaming it in project One will miss all Code in project Two. Renaming it in project Two will also catch code in project One. There are more caveats, that I couldn't reproduce in a small and artificial environment like this (though they reproduce well in our production setting...): We have three projects, depending on others. On some renamings, classes seem to be affected more than once, so their call to aMethod will not be changed to aRenamedMethod, but to aRenamedMethoddMethod (the name is "Renamed".length() longer than it should be, so it seems that the refactoring is done twice. This can be anticipated in the preview, where the code is correct, but a class will appear twice, causing this issue. I know that Creating a linked folder to another place in the repository gives a warning ("Location ..... may overlap another resource. This can cause unexpected side-effects."), but only once upon creating it. I'll investigate further and try to reproduce everything in a smaller setting if (to the dev team) it seems worth fixing this issue. I wouldn't want to do if this bug is rejected (i.e. WONTFIX, unsupported feature). Please tell me.
With this configuration, search engine is not able to find references as there's no link between project One and project Two. To fix this you have to make project One dependent from project Two... Then, searching for reference to src/one.ClassOne.aMethod will get match in ClientOfClassOne constructor. However, this does not sound really nice as it sounds more that project Two depends on project One that reverse way. IMO, the best solution is to remove the link folder "src_one" in project Two and make this project dependent of project One. Applying project depency in this way would be more intuitive (your current project naturally depends on project where all *common* generated classes are) and would make search engine working correctly now for free. Hope this is clear enough. As you thought, I set this as WONTFIX, as current behavior is the expected one and your issue really looks like projects setup problem. Feel free to add questions/remarks on this bug if you find problem with your configuration and any of the 2 suggested setups...
I suspected this WONTFIX. One more Question though: I can live with rename not supported through linked folders, but having rename "done twice" in this case - e.g. renaming "aMethod" to "aRenamedMethoddMethod" is really bad - I'd prefer no refactoring done in this case, rather than plain wrong... Is it worth to try to reproduce this? Is it possible for the search engine to detect that some resources might be included twice (e.g. via absolute path to resource)? Currently this is done once when creating linked folders, whereas the described errors happen later, when the warning is (long) forgotten. But then: I'd better go clean up my projects file structure.
