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 realize this might not be applicable to module sample projects - have been discussing this topic with developers of other sample projects and have filed similar issues, so thought it might apply to module samples as well. please reassign to correct subcat - I didn't see one for samples. part of this might be related to new project encoding property and part is related to encoding handling for generating javadoc assumption here is that it is ok for user to change some labels or other ui items part of using the sample. And it might be that the created project might have multibyte in it anyway if project name has multibyte in it and thats used as name of package or class, or that date is part of the temate and so would have mbyte characters in it. 0. this is for the module sample projects - - the default case now for module projects is that utf-8 encoding is used but if encoding was changed in another project, that encoding becomes the global encoding value. (is this true for module projects in general or is utf-8 always used ?) 1. when multibyte is added to some label and thus its then in the java code, when compiling the project or when generating javadoc, some warnings about encoding are shown but the project and javadoc compiles ok. 2. the fix for javadoc has been filed for various project types; the fix relates to javadoc.encoding property defined in the project.properties wasn't used only defined. 3. the regeneration of the sample projects for nb6 could help with these warning since the build-impl.xml will also be regenerated. Tomas can provide more information on these topics. 4. Also, these samples might have jsp or html files in them and the encoding value used in creation of these files is different than in past, and works with the new project encoding, so regeneration of the samples might help those files in the samples to be compatible with that.
I'm not really sure what this is about. Module projects always use UTF-8 encoding, and none of our samples currently use non-ASCII chars in source code that I know of. If you have encountered a specific problem, please reopen with detailed steps to reproduce.
reopening with more info first of all, typo in summary referred to moblity samples instead of nb module samples. this is seen, at least on solaris, when have paint app in folder with multibyte in a java file - would this happen for paint app (besides comments ?) Can users change some part of the app as to UI and as part of that have multibyte in a label and thus have it be in the code ? (and thus the warnings would happen) its not related to having mbyte be in the path to the project. see attached gif for the warnings, but the javadoc does compile. clean and build does work ok, which is different than was in other sample projects, where the warning was seen there. 1. create paint app, on solaris, in ja locale; am using pseudo localized nb but thats not important since this is not about messages/labels 2. add some multibyte to java file - even comments. 3. go to the Paint project and choose generate javadoc 4. warnings similar to seen in attached gif will be seen. 5. default encoding was not changed of this project nor of other projects in this ide or other ide session with same userdir. 6. also, and perhaps unrelated - see 2nd gif for the top line in left side of browser that shows the javadoc - the mbyte is not correct - this is from something from translation of javadoc msgs - when choosing the view->encoding to use the same encoding as chosen now, the mbyte shows ok. --> so if its not allowed or would not normally happen that mbyte would not be used in the paint or other sample, and #6 is not a problem, then this can be reclosed. ken.frank@sun.com
Created attachment 44849 [details] image
Created attachment 44850 [details] image
Specifying encoding for <javadoc> therefore. Checking in nbbuild/javadoctools/template.xml; /shared/data/ccvs/repository/nbbuild/javadoctools/template.xml,v <-- template.xml new revision: 1.73; previous revision: 1.72 done Checking in apisupport/harness/release/build.xml; /shared/data/ccvs/repository/apisupport/harness/release/build.xml,v <-- build.xml new revision: 1.27; previous revision: 1.26 done
v