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.
Created attachment 107064 [details] project for demonstration of described behavior I've been using the NbBundle.Messages annotation introduced by https://netbeans.org/bugzilla/show_bug.cgi?id=192750 a few times now. Through that i've stumbled upon a problem. Once i start using the Annotation in a package i am forced to use it everywhere in that same package due to the fact that only the generated Bundle.properties is deployed to the .jar file. That in turn can result in MissingResourceExceptions during runtime. That leads to either converting all NbBundle.getMessage() calls to the static Bundle.** methods or the creation of a .properties file with a name other than Bundle and using that file explicitly (which in case of panels can be quite a few). Attached is a small demo project that IMO should not throw a MissingResourceException. As a side node it would be nice to have some better error message if a generated message exists in the preexisting Bundle.properties file. Currently the declaring .java file is marked as erroneous while a clean, build and run succeeds.
The processor does in fact load Bundle.properties from your sourcepath, appending to any keys found there, and checking for duplicates against it. (All covered by its unit test.) Both of your problems are reproducible only in a j2seproject; works fine in an Ant-based NBM project, and running works in a (jar) Maven project using src/main/resources though the dupe error cannot be produced (due to a Maven workaround for a bug in JDK 6 javac relating to multiple entries in -sourcepath). The reason for the failure in j2seproject is that an empty (or rather dummy) -sourcepath is passed, which makes it impossible for the annotation processor to load Bundle.properties. Note that F9 on MessageTest behaves as expected, since compile-single does pass a sourcepath. I don't know if there is any way around this other than not supporting compiler excludes, i.e. by adding to build.xml: <target depends="init,deps-jar,-pre-pre-compile,-pre-compile, -copy-persistence-xml,-compile-depend" if="have.sources" name="-do-compile" xmlns:j2seproject3="http://www.netbeans.org/ns/j2se-project/3"> <j2seproject3:javac gensrcdir="${build.generated.sources.dir}" sourcepath="${src.dir}"/> <copy todir="${build.classes.dir}"> <fileset dir="${src.dir}" excludes="${build.classes.excludes},${excludes}" includes="${includes}"/> </copy> </target> to restore behavior similar to that prior to the fix of #49026. More generally, any annotation processor which calls processingEnv.getFiler().getResource(StandardLocation.SOURCE_PATH, ...) is not going to work in a j2seproject using an unmodified build script. Assigning to Tomas in case he knows of any way to support SOURCE_PATH without breaking includes/excludes support, but I think this will be WONTFIX. (Could pass a sourcepath if and only if no includes or excludes are defined, but then defining a no-op exclude like "does/not/exist/anyway/" would cause subtle and unexpected changes in the build.)
I am afraid it's impossible to support excludes without empty source path.
Right. So either 1. Use a different project type (designed for use in modules anyway); or 2. Add the snippet to your build.xml.
Other than using the 199 APIs to launch the compiler with a custom JavaFileManager, I just thought of an alternative to omitting -sourcepath which would still assure that attempts to refer to an excluded class from an included class will result in a compiler error (so that you do not accidentally create a subset of the tree which is not a transitive dependency closure). Invoke javac normally with a sourcepath, but after it completes (assuming it succeeds), scan the build/classes directory for class files not matching the include/exclude pattern. If any are found, fail the build (or perhaps just issue a warning that the subset of the tree is not self-contained). It is a bit tricky since the patternset is defined in terms of *.java whereas you will be encountering *.class, including nested classes and even private top-level classes which are not relevant. So the check should be to see if there are any src/${path}.java for which build/classes/${path}.class exists and ${excludes} matches ${path}.java or ${includes} does not match ${path}.java. I think this is possible with some advanced Ant scripting (<mapper> etc.).
Jesse, do I understand correctly that you want to let the javac to compile included classes + closure. If the compiled closure contains some excluded classes abort build with error (warning). Right?
Yes, that is a good summary.
*** Bug 200090 has been marked as a duplicate of this bug. ***
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss