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 found bug related to non ascii characters presence (É for example) inside java source (in string literals). All java files are UTF-8 encoded. Encoding is set inside maven2 pom.xml and recognized by NB (project->properties->sources). Project tree shows errors in some (few) java files. When I open any one of them in editor, editor does NOT show any error, and after closing, error mark disappears in project tree. Later, when background compilation step passes, same java file is error marked again. So it looks like background compiler is bad boy.
I have took a look at the FileEncodingQuery impl in maven support, and it seems to me that it is possible that the query does not return the correct encoding when the encoding is requested for the whole source root (it seems to use FileUtil.isParentOf(f1, f2), which returns false if f1 == f2, which is I guess the situation when the encoding is required for whole source root). Milos, any ideas?
ok, possibly a bug in maven support then. *if* asking for encoding for a folder is documented contract. I've always assumed one asks about encoding for files only..
The Java infrastructure calls FileEncodingQuery on the source root and uses the return value for the whole compilation unit. The reason for this the fact that the project queries are incredibly slow.
fixed both in trunk and the 3.0.x branch (current release branch) http://fisheye.codehaus.org/changelog/mevenide/?cs=5154 http://fisheye.codehaus.org/changelog/mevenide/?cs=5156 please use the nbm files from the continuous integration machine to verify: http://deadlock.netbeans.org/hudson/job/mevenide-fcs/lastSuccessfulBuild/artifact/mevenide-AU-SNAPSHOT.zip Note: I'm not sure if we do another respin of 3.0.x branch or wait a few weeks til the 3.1.x codebase is ready to be pushed to AU.
I suggest we respin the modules for 6.1 UC soon (before 6.1 FCS).
It works now. Thanks
to nb developers - is there any use case or situation that might need to be fixed for other modules or for feq api itself that could impact other modules ? ken.frank@sun.com
v.