This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have one project, project 'A' (webapp), depending on project 'B' (jar). I put B in the project A's lib dependency. When I refactored a class name in project 'B' - MySimpleFilter to SimpleFilter it first was correctly detected in Project A and B, but only correctly refactored in B, while messing up the code in A. Original Code: ... import org.elena.lr.filter.MySimpleFilter; import org.elena.modules.networksearch.QueryTargetStatusBean; ... MySimpleFilter filter = null; try { URL ontologyConfig = new File(WafConfig.getApplicationBaseDir() + "/conf/skills-linginfo.rdfs").toURL(); MySimpleFilter.setOntologyConfigFile(ontologyConfig); MySimpleFilter.setOntologyBase("http://www.elena.org/ontologies/skill#"); MySimpleFilter.setSaveResources(true); filter = new MySimpleFilter(); } Refactored Code: ... import org.elena.lr.filter.SimpleFilterimport org.elena.modules.networksearch.QueryTargetStatusBean; ... SiSimpleFilterter = null; try { URL ontologyConfig = new File(WafConfig.getApplicationBaseDir() + "/conf/skills-linginfo.rdfs").toURL(); SimpSimpleFiltertologyConfigFile(ontologyConfig); SimpleSimpleFilterlogyBase("http://www.elena.org/ontologies/skill#"); SimpleFiSimpleFiltersources(true); filter = new SimpleFiltSimpleFilter} This happened not in only one file but several other files as well I tried to reproduce this with sperate classes in both projects, but could'nt. Tom
There must be some problem with positions.
Had this problem again. I realized that when this happened, I had double entries in the refactoring preview. Like .... xyz.java ..... ..... xyz.java ..... ..... but not always with the same subtree.
Created attachment 22413 [details] Screenshot of Refoctoring window
As seen in attachment the Refoctoring window has several double entries - if i leave them checked then the code will be messed up, if i uncheck the doubles the code will be fine....
How is your project set up (free-form, from esisting src)? Could you provide some details about what packages are in what project and what you are actually refactoring? The best would be if you could provide the project (if it's not confidential) and exact steps how to reproduce the problem starting with clean userdir.
I remeber we had similar problem, it should be fixed in NB 4.2. Please verify.
This issue is still not resolved - see issue <a href="http://www.netbeans.org/issues/show_bug.cgi?id=71539">71539</a> Unfortunately I can not provide you with the source, but the next time i stumble over it i try to provide a demo package. Our project structure is something like this +-Web Pages +-WEB-INF +-test +-styles +-bin +-html +-META-INF +-conf +-database +-docs +-src +-logs +-images +-lib +-index.html +-build-user-example.properties +-build.xml +-build-user.properties ... +-Source Packages ... +-Test Packages ... +-Libraries +-Test Libraries ... It was created trough New Project/Web/Web Application with existing sources. The Project Folder (eg. /develop/myProj_nbProjects) lies two levels higher than the Web Pages (eg. /develop/myProj/trunk/CVSProj/) Folder. The build.xml is not a netbeans build.xml file. Hope this helped a bit :) Reopening this issue
sorry for the link above, but apperently I've no idea how to reference to another bug in that way, so it displays only the bugid and I can still click on it... But anyway, I wondered, if you could provide a small nbm module which could install in netbeans and when I start it, it will gives you all the information you'd need to track this back down. For example it could give you all the backgroundinformation on the currently open refactoring confirmation window, showing all the dublicate entries together with where they come from :=) I could then attach the log to this bug, what do you think?
*** Issue 71539 has been marked as a duplicate of this issue. ***
The problem probably is, that your source is twice on the classpath: under the Web Pages/src and Source Packages. Can you verify, that this is your case?
yep - that's right :) So I guess netbeans should check that and avoid putting the source into the classpath twice?
Project system should check this
Project code cannot check it, it does nothing about the project source path. It's up to the project type to do it. J2seproject does it. Has to be handled in the web/project.
Maybe I do not understand. But it is not possible to add the same source root twice in the Web Project's customizer. Maybe it was fixed. Is this issue still relevant? If yes, could I have some better steps to reproduce? Thanks in advance.
I'm really not sure what is wrong. I tried to add the same source twice, it's not possible. Also with the same package/Clazz.java in multiple source roots I was not able to simulate the problem. Also the issue is somehow old. No feedback, so presumably it was fixed somehow? Please reopen with steps to reproduce in NetBeans 5.5. Thanks.
Created attachment 30231 [details] Mulitple occurances of same method when rename refactoring
In the Refactoring_Rename_messedup.png attachment you can see another web project, which is similar to the one above, which was created from source, where the nbproject files are seperated. When I tried to rename getPasswordChangeOKSessionID() to getPasswordChangeOKSessionID1() it listed several things twice in the confirm refactoring dialogue - The class was registered twice and the refactoring action also in one class. Again - if you could provide me with a 'debug' nbm extension which simple lists the interesting information for you - i could just post you back the information it gathered. My workaround so far is just to deselect all nodes which are listed twice, but thats quite cumbersome, especially when the list of refactorings is large. I REOPEN the bug
I do not know about any "debug" flag right now which could be useful. However I tried to reproduce your scenario in serveral ways again (with nbproject separated) and I still without "success". But your screenshot is clear. What would help is detailed steps to reproduce with some dummy project. E.g. I tried. 1) Creating new "Web Project" SomeWebPrj 2) Create a testing class with a method 3) Then close it, deleted its nbproject directory from disk outside of IDE 4) Run "Web Project with Existing Sources" wizard using SomeWebPrj folder as 'Location' on the first step of the wizard 5) Try to play with renaming of the testing method and/or class in the project created in step 4. 6) Everything worked ;) Something reproducible like this would help a lot.
oddd, odd, odd... I tried to reproduced - created a lot of new project with the same source... I found out .) when I created a new project (project TestX) based on the same project (MetaRepository) and tried to rename the method in Porject X it seemed to use the classpath from Project MetaRespository, since it showed all double listings in the confirmation dialogue again, but when I closed MetaRepository (& restarted IDE) it renamed WITHOUT listing things twice. .) When ever I created a new project from source (deselcted 'create war') when MetaRespository was closed it worked just fine .) NOW the funny part. I compared build/project scripts from the newly created files and the MetaRespository project and the only difference seemed to be that i did not mount the test directory - so i did that in the newly created projects too - and PHEW - the confirmation refactoring window was messed up again. So i just removed the test file directory from the MetaRepository project and WOW, the refactoring seemed to work - I DID NOT check ALL files and refactorings, but I GUESSED it will work with the others too - I don't know what the problem would be. I also got a warning every time i wanted to rename the method (which i did not get when I removed the rest directory from the project) WARNING: 'There are methods in subclasses/implementors of edu.universaladministration.usermgmt.UserPrefsHandler that override or implement this method. They will also be renamed.' But i could not find any class in the test directory that would implement or extend UserPrefsHandler. I also could not find any method called 'getPasswordChangeOKSessionID' when 'find'ing it.
Odd (Ctd.) Again, it seems to work with NO test directory mounted. Now, I created a empty test2 directory and mounted it in the project - And again, same warning and the double listing in the refactoring dialogue. Soooo, it seems it doesn't have anything to do with what is IN the test directory, only the fact that it is mounted is enough. Only thing i got in the |Compile Test| Tab is 'Compiled Source', 'Classpath for Compiling Sources', JUnit
Sorry tomzi. I'm still not able to reproduce. Having test source root or not in various ways, trying combination of NB 5.0, 5.5 and 6.0 dev builds.... I must be missing some step. You built all your description on MetaRepository project which surely I do not have. Also not sure if that would help. The really best would be to provide steps to reproduce similarly to my steps in my previous comment, if you are able to reproduce in such way. I.e. ideally with clear userdir, with projects created by the IDE (then adjusted), .... and so on, as I did. With such simple and clear steps to reproduce we would surely could move further. Thanks for the feedback.
Yes, you are right and I'm aware of that :) Maybe I just copy the whole project and strip it down to a minimum and see what happens at each step. I could also send you the nbproject files, if that helps... But today I got no time for that - maybe next week...
> I could also send you the nbproject files, if that helps... This is what I'm not sure about. Of course I would prefer (1 - the best): 1) steps to reprocude with clean userdir without MetaRepository project ;) 2) somebody elese (e.g. from QA) who is able to help_with/reproduce this 3) sending nbproject Also if you could try it with NetBeans IDE 5.5 dev build or upcoming beta...
Closing as WORKSFORME. Tomzi if you are able to reproduce, ideally in the way we discussed (some latest q-build or daily-build of NetBeans with fresh userdir, ideally also a new fresh project, ...), please reopen again.
> ....some latest q-build or daily-build of NetBeans... sure, NetBeans 5.5
Created attachment 35130 [details] DoubleRefactorings
Here we go, i did a little bit of experimenting, after I had the 'annoying' refactoring problem again - and I am glad this little voice in my head said: 'Don't give up, give it another try' So here we go: .) Import the 'DoubleRefactorings' project. I used the ProjectPackager plugin, but I also tried it with simple unpacking/'Open Project' -> You will see a project with 2 Source Packages Folder. You can find 'Source Packages 2' in the 'Web Pages' folder (/web/src2). And I think that's where the problem is! 'Source Packages' is as usual under /src. .) Now open ProblemClass in 'Source Packages 2' and refactor ALT-SHIFT-R method 'problemMethod' to something else. -> In my Refactoring view the method is now listed twice!!! (I hope in yours too) (Using NB 5.5RC1)
Can you verify the behaviour?
I just downloaded NB 5.5RC2. This issue is not fixed there, so I reopen this issue. At least, I think, it is reproducable with the 'DoubleRefactorings.zip' project. Hope this can be fixed for the final release :)
The source structure is rather non-standard. Why do you put src2 under web? Radko, can you please take this back from Martin? Thanks.
From my initial evaluation and debugging it seems that the problem is not caused by web/src2 but by web/test. Place your test folder somewhere else than under web folder and the refactoring problem should disappear. Reason: ClassPathProviderImpl.getType() returns 5(web pages) instead of 1(test source) and then incorrect classpath is computed for refactoring.
As I wrote on Feb 9th, this is the source code structure we have in our project, since 2001, where there was no 'real' standard. We used to have our own build script then, but since nb4.0 the build environment grew more and more flexible, so we started to use netbeans build environment. And it does work very well! But in our 'old' project we have a lot flatter source sturcture than netbeans would expect. And that's, I guess, the problem.
Yes, what I meant was to place the test folder somewhere else just like a workaround till it is fixed (or remove web/test from project properties).
Ha, interesting, so this bug is then probably related to #85220, #85221, #85223. Since in our project the 'test' folder is within the 'web/' folder, I can not run create any test there ... Here I created a web/test folder, added it to properties. Then I .) created a testcase (New Emtpy test) there -> Throws Exception .) created a testcase from a class -> Throws Exception .) created a class (org.NewClass) -> puts it into package test.org
Since this situation only happens in a very specific case with a particular source structure (that is very uncommon), we determined this is not a showstopper for NetBeans 5.5. Requesting a waiver for NB 5.5.
Fixed. RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/web/META-INF/context.xml,v done Checking in test/unit/data/projects/WebApplication59055/web/META-INF/context.xml; /cvs/web/project/test/unit/data/projects/WebApplication59055/web/META-INF/context.xml,v <-- context.xml initial revision: 1.1 done Checking in src/org/netbeans/modules/web/project/classpath/ClassPathProviderImpl.java; /cvs/web/project/src/org/netbeans/modules/web/project/classpath/ClassPathProviderImpl.java,v <-- ClassPathProviderImpl.java new revision: 1.25; previous revision: 1.24 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/project.xml,v done Checking in test/unit/data/projects/WebApplication59055/nbproject/project.xml; /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/project.xml,v <-- project.xml initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/build-impl.xml,v done Checking in test/unit/data/projects/WebApplication59055/nbproject/build-impl.xml; /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/build-impl.xml,v <-- build-impl.xml initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/.cvsignore,v done Checking in test/unit/data/projects/WebApplication59055/nbproject/.cvsignore; /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/.cvsignore,v <-- .cvsignore initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/ant-deploy.xml,v done Checking in test/unit/data/projects/WebApplication59055/nbproject/ant-deploy.xml; /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/ant-deploy.xml,v <-- ant-deploy.xml initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/project.properties,v done Checking in test/unit/data/projects/WebApplication59055/nbproject/project.properties; /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/project.properties,v <-- project.properties initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/genfiles.properties,v done Checking in test/unit/data/projects/WebApplication59055/nbproject/genfiles.properties; /cvs/web/project/test/unit/data/projects/WebApplication59055/nbproject/genfiles.properties,v <-- genfiles.properties initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/src/conf/MANIFEST.MF,v done Checking in test/unit/data/projects/WebApplication59055/src/conf/MANIFEST.MF; /cvs/web/project/test/unit/data/projects/WebApplication59055/src/conf/MANIFEST.MF,v <-- MANIFEST.MF initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/web/index.jsp,v done Checking in test/unit/data/projects/WebApplication59055/web/index.jsp; /cvs/web/project/test/unit/data/projects/WebApplication59055/web/index.jsp,v <-- index.jsp initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/build.xml,v done Checking in test/unit/data/projects/WebApplication59055/build.xml; /cvs/web/project/test/unit/data/projects/WebApplication59055/build.xml,v <-- build.xml initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/.cvsignore,v done Checking in test/unit/data/projects/WebApplication59055/.cvsignore; /cvs/web/project/test/unit/data/projects/WebApplication59055/.cvsignore,v <-- .cvsignore initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/web/WEB-INF/web.xml,v done Checking in test/unit/data/projects/WebApplication59055/web/WEB-INF/web.xml; /cvs/web/project/test/unit/data/projects/WebApplication59055/web/WEB-INF/web.xml,v <-- web.xml initial revision: 1.1 done Checking in test/unit/src/org/netbeans/modules/web/project/classpath/ClassPathProviderImplTest.java; /cvs/web/project/test/unit/src/org/netbeans/modules/web/project/classpath/ClassPathProviderImplTest.java,v <-- ClassPathProviderImplTest.java new revision: 1.6; previous revision: 1.5 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/web/src2/org/wa59055/extra/Class2.java,v done Checking in test/unit/data/projects/WebApplication59055/web/src2/org/wa59055/extra/Class2.java; /cvs/web/project/test/unit/data/projects/WebApplication59055/web/src2/org/wa59055/extra/Class2.java,v <-- Class2.java initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/src/java/org/wa59055/Class1.java,v done Checking in test/unit/data/projects/WebApplication59055/src/java/org/wa59055/Class1.java; /cvs/web/project/test/unit/data/projects/WebApplication59055/src/java/org/wa59055/Class1.java,v <-- Class1.java initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/web/test2/org/wa59055/extra/Class2Test.java,v done Checking in test/unit/data/projects/WebApplication59055/web/test2/org/wa59055/extra/Class2Test.java; /cvs/web/project/test/unit/data/projects/WebApplication59055/web/test2/org/wa59055/extra/Class2Test.java,v <-- Class2Test.java initial revision: 1.1 done RCS file: /cvs/web/project/test/unit/data/projects/WebApplication59055/test/org/wa59055/Class1Test.java,v done Checking in test/unit/data/projects/WebApplication59055/test/org/wa59055/Class1Test.java; /cvs/web/project/test/unit/data/projects/WebApplication59055/test/org/wa59055/Class1Test.java,v <-- Class1Test.java initial revision: 1.1 done
If there is an update of NetBeans 5.5, I propose to add this fix into it (http://wiki.netbeans.info/wiki/view/NB55Fixes)
Yes please do :) definately voting for this
verified in 200611291315
The issue has been fixed in the release551. Checking in ClassPathProviderImpl.java; /cvs/web/project/src/org/netbeans/modules/web/project/classpath/ClassPathProviderImpl.java,v <-- ClassPathProviderImpl.java new revision: 1.19.20.2.2.4.6.1; previous revision: 1.19.20.2.2.4 done