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.
[ BUILD # : q2040910 ] [ JDK VERSION : J2SE 1.5.0 ] In the tools>Internationalize>internationize... dialog, the browse... button for bundle name does not show the acutual code bases for the project, but instead shows the classpath for the project. This is a break since Beta 1, and makes the internationalization dialog completely useless. Project is a free-form project, that seems to matter a lot. Either fix it or add it to the "not implemented for this release" list and remove it.
I tried reproduce it and it doesn't work for me too. I play with config files and now it works for me. Workaround is : Add the source directory to classpath. Steps: - Open project properties in Project tab - Select "Classpath" item from Project properties dialog - Add folder - your source directory The browse button for bundle name shows the source tree with bundles.
Danno thanks for report, it seems like you are right. Just to be sure steps to reproduce: - open freeform project - don't add source root at the classpath - try to Internationalize some java class from the source folder -> there is no source root on the I18N Resource wizard As David mentioned, it seems like something is broken on freeform project side... David, please look at this, thanks in advance.
This worked for Beta1 because it had been built before issue 47206 was fixed. Now it is broken because EXECUTION classpath (when not explicitly specified in project.xml what is usual case) is equal to COMPILATION classpath which does not contains sources (line 393 in org.netbeans.modules.ant.freeform.Classpaths.java). Fix I guess should be matter of adding all source roots to the classpath. I will look at that.
Created attachment 17684 [details] patch proposal
Attached is patch which solves the problem. I wait for Jesse to hear his opinion. Re. "// XXX but add built-to dirs" comment in the createExecuteClasspath() method: once this is implemented and there is a built-to file specified, the source packages can be omitted from the EXECUTION classpath, right?
Ok, David thanks . Do we want fix for Beta2 ? - it's regression against Beta 1 - reported as P1 by one of the NetCAT participant
The patch is trivial and should not have any sideeffect, but this part of freeform was implemented mainly by Jesse so he has the last word.
The patch is wrong. EXECUTE should not contain sources, it should contain built-to dirs as mentioned in the comment. The internationalize dialog should be mapping these back to the sources indirectly. I don't have a strong opinion about putting the current patch into beta2 - if it solves the problem easily, may be OK - but it is not correct and should be fixed properly in the trunk. I will see if I can fix it in conjunction with issue #47807.
"EXECUTE should not contain sources, it should contain built-to dirs as mentioned in the comment." - technically this is more correct. But practically if you do not specify output jars (which is optional step) the I18N will not work. Can it have a negative sideeffect having sources on the EXECUTE classpath? AFAIK, this classpath is not used by Freeform for anything. Also we talk about case when there is no explicit EXECUTE classpath specified in project.xml and we are trying to guess some. From this point of view some incorrectness seemed acceptable to me. One improvement I had been thinking about (for trunk) was to check <built-to> and if something is presented return it instead of sources.
Yes, I would probably include the source dir in case no <built-to> was specified, as a fallback.
Sorry, this is unrelated to issue #47807, I was confused.
I have a better patch that also uses <built-to> if available. Not too complicated, seems to work.
Created attachment 17700 [details] Better patch
Ok, I don't know much about the internals of the project source, but should we be looking for the soruce folders and not the runtime folders? Internatnionalize... will need to change the _sources_ for those messages, it's not reading the value from the results. I.e. data from project/configuration/general-data /folders/source-folder/location or /project/configuration/java-data/compilation-unit/package-root, and not data from class-path or build to, which are not source files but output files. Also, this breaks the text editor in resource bundle mode for setting fields in the form editor. looks like they use the same panel. This is a very signifigant regression now, internationalize... may have been used by very few but this dialog is seen a lot more often in internationalizing GUIs. I don't want any of the junk from execute classpath, or other class paths. IMHO the only folders that should be shown (as was the case in beta 1) are the source folders listed in the create wizard and the customizer as source folders. My look at the patch #2 seems to indicate that I will see all of the classpath entries (which won't be editable anyway).
Ok, I read BUG 47206 and now see that some people want to mount random jars, but this was done at the expense of source jars. The rationae was quite myoptic, because at my company, and at several open soruce projects resource files are kept in the java source trees. The more appropriate fix for that would have been in my opinion to have the user add the resources tree to the source. Perhaps the solution should be for the resource bundle to look at source classpath and execute classpath, with source classpath first (since this is the more common usage pattern). Trying to find the source dir for imported jars doesn't seem right to me, the sorce dirs as specified in the project should be first class citizens since one of the essential features of that panel is the ability to create new resource keys and values into the properties file.
Danno - I think you misunderstand. The internationalize dialog takes the execute classpath, then tries to map entries back to source dirs where possible. When you have the built-to dirs/JARs listed in the execute CP, then it maps them back to the source dir, as desired. This is used by other things too, like the background error compiler, etc. This patch simply makes the freeform project behave like the other project types do already. committed * Up-To-Date 1.10 ant/freeform/src/org/netbeans/modules/ant/freeform/Classpaths.java committed * Up-To-Date 1.10 ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/ClasspathsTest.java
Jesse, is the fix safe ? What do you think about fixing this for Beta 2 ?
I reviewed new patch and it looks OK.
Don't fix for Beta 2. Too late, no time to verify the fix. It's already in trunk, so the final relase will get it. For Beta 2 workaround exists: "Add the source directory to classpath." We may want to release note this. Is it just the I18N feature? Are there any other scenarios where this bug can manifest itself?
It also affects at least the String customizer and int customizer in the form. For String it's the ResourceBundle mode and int the two Internationalized modes. So this will be in the Sep 21 Q build once promoted?
There won't be a Q-build on Sep 21. We're in the Beta 2 stabilization mode now and all test cycles are spent on that. Unfortunately, Beta 2 was branched before Jesse's fix, so it won't include it. The fix will be available in the daily dev builds.