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 moved a class to a different package/module and all NbBundle.getMessage(SomeClass.class,"XXX") were correctly updated to new class but resources stayed in original bundles. Please reassign if this should be handled by properties or some other module.
properties module should implement its refactoring plugin.
This should be address for 7.0. I just moved a form between two NB modules and result is that all my bundle values like 'org.openide.util.NbBundle.getMessage(AntArtifactChooser.class, "LBL_AACH_ProjectJarFiles_JLabel")' were replaced with '"null"' which now I have to go and fix by hand. Thanks.
I doubt we will be ever able to fix this. Moving/copying entries in properties files based on analyzing java code that might use it is quite messy. There are many patterns that can be used, the reference to the properties file is often a String that may need to be changed. If it is a String with full resource name, it remains valid if the class where used is moved within the same project classpath (no change needed). If the class goes to another project, the properties files becomes unreachable. Where should the new one be created for the moved class? Case like NbBundle.getMessage(...) where class is used as the reference point is better (at least the code itself does not have to be changed, it is stable for package renames), but it is specific to NetBeans sources (so does not solve our real users problem). In all cases, moving an entry is risky since it might be used by other classes (it's hard to find out that). OTOH copying leaves unused keys behind. Also finding all the usages of the get code patterns for all moved/copied classes would likely slow down the refactorings significantly. And it looks like the user would have to care about the properties file after such a change anyway... The way the properties files and their usage is designed is simply very unsuitable for integration with refactoring. E.g. Swing App Framework does that much better - each java file has its dedicated properties file with defined name and relative location. Moving a java file just means moving its properties files as well. That's all. Also the auto-i18n pattern that can be used in GUI forms allows for more deterministic moves. But the general properties files usage is unmanageable. So I'd suggest: * Not to try to correct general ResourceBundle getter code and move properties files entries accordingly. * Not to try to fix NbBundle.getMessage use - it's for NB developers only. If you think it is needed anyway, file issue on API support. * Fix form's auto-i18n support to handle moves between projects - I suspect it fails now. * Fix form not to generate "null" in case it cannot find the properties file. * RFE: make form move i18n values in more cases than just the auto-i18n pattern, e.g. if the value comes from a properties file in the same package as the form itself.
Re. "Fix form not to generate "null" in case it cannot find the properties file" - this still qualifies for P2 and I filed it as separate issue 150287. I do agree that it is difficult to implement refactoring of properties used by form. My view is that we should at least try and do our best, possibly issue some refactoring warnings to user and let them decide in refactoring preview. I was refactoring several J2EE projects and was moving forms around a bit and IDE was totally unhelpful and sometimes I was better moving files outside of IDE and do search/replace instead (issue 150287). Try it yourself and you will agree with me. :-) I had to move properties between bundles by hand and I did not know either whether a property can be safely moved and should be copied - again no help from IDE so I had to use search most of the time. It is not surprising I caused handful of P2s because of MissingResourceException. How could IDE help me prevent them: * Show Unused Bundle Keys in my project- even if it is not 100% correct * Show Missing Bundle Keys in my project As for refactoring: something is better than nothing. In my J2EE projects usecase let say I had to do 50 changes in total by hand. I would be much happier if IDE did 30 or 40 of them for me. As of NB6.5 IDE screws up during refactoring and increases the number of changes I must do to at least 80! Thanks for the help I will use you again. :-) Would I mind waiting little bit longer to get my source refactored properly? No!
*** Issue 151759 has been marked as a duplicate of this issue. ***