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.
nb6 has concept of project file encoding, which was not there before. default project encoding is utf-8 until user changes it in some project, then newly created projects use that encoding and show it in project props. for web svc samples, the project encoding shown is utf-8 even in cases where the current global project encoding is something else. current sample web projects have related issue filed; in their case they use the encoding of locale user is in for the project encoding, vs utf-8 for these web svc samples. additional info is below - since other steps might need to be done; contact Tomas Zezula for details: -- 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 - and regeneration can help avoid issues with javadoc not generating due to encoding problems 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. that is, now jsp, html and xml files seed their newly created files with encoding of project, not UTF-8
please fix this soon so we can have uniform behavior of all projects and samples related to encoding and other things mentioned below. ken.frank@sun.com
I'm not able to regenerate the samples because the build doesn't work - see blocking issues. If I understand it correctly, it's not about regenerating samples. It's about generating them dynamically based on the current encoding value. That's not the same thing - it's much more than regenerating them. Or do I not understand the issue correctly? Where is a document that describes what has changed and what exactly needs to be done? More, I found http://www.netbeans.org/issues/show_bug.cgi?id=108903 filed as a P3, thus decreasing priority to match priority as these are exactly same issues. I'll fix it once I know what exactly needs to be done and once build is working fine.
The info here is all I know about it; I 'm not a developer; got the info from Tomas Zezula and he can tell you more. It may be that its more than regenration of sample; that seemed to be wording that I saw and that I've been using for whatever is related to fix the problem described here and other things feq and eencoding wise that might not work well if the additonal steps and regeneration is not done. It looks like I either did file others at p3 vs p2 or those were changed to p3 but in any case, I do belive its needed to be fixed so consistent as to feq with other project types and so not to have incorrect effect on feq also; looks like just web, j2ee and this one are not yet done on this topic. ken.frank@sun.com
OK, I asked Tomas for more info.
I got info from Tomas. I will regenerate the samples, but I'll do it after Beta2 as I see move still in the project build files, definitions, properties, ... so I'd still have to do it after beta2 anyway.
I regenerated all the samples. Have to say that is a hassle since a lot of things is changing in the meantime.
I do realize it is a hassle, it was filed based on the advice and guidance from development; I did not just choose to file it for no reason. as to the changes still happening, does it mean the samples would need to be regenerated again to fix the things mentioned in this issue ? ken.frank@sun.com
It depends whether there will be a bigger changes in the web project layout. They are not expected, because the issues I mentioned have been already fixed before I regenerated the samples.
the encoding of the project is still utf-8, regardless of what the current project encoding value is. I dont know if its ok for samples or not; that is, other samples are using current project encoding and thus I don't know if they all need to have consistent behavior; I think they should at least so user not get confused about what the encoding is. when a new project is created, however the utf-8 is not used for that other new project, if not another ws sample, but the current project encoding is used. if this is still problem due to other fixes and changes that have happened and are in progres since this last fix was done, I suggest waiting until after code freeze this week before doing any more fix on it. ken.frank@sun.com
verified using trunk build 0529. Samples encoding looks always UTF-8. it seems decided that it is ok. Project encoding doesn't depend on this. I created a project using win-31j then created a sample (utf-8) and after this created another one new project. It had win-31j.