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.

Bug 196789 - SOURCE_PATH does not work in AP run in j2seproject
Summary: SOURCE_PATH does not work in AP run in j2seproject
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 7.0
Hardware: All All
: P3 normal (vote)
Assignee: Tomas Zezula
: 200090 (view as bug list)
Depends on:
Blocks: 49026 192750
  Show dependency tree
Reported: 2011-03-16 19:55 UTC by mklaehn
Modified: 2016-07-07 07:17 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

project for demonstration of described behavior (16.79 KB, application/zip)
2011-03-16 19:55 UTC, mklaehn

Note You need to log in before you can comment on or make changes to this bug.
Description mklaehn 2011-03-16 19:55:58 UTC
Created attachment 107064 [details]
project for demonstration of described behavior

I've been using the NbBundle.Messages annotation introduced by 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 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 file. Currently the declaring .java file is marked as erroneous while a clean, build and run succeeds.
Comment 1 Jesse Glick 2011-03-17 15:04:42 UTC
The processor does in fact load 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 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="">
        <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}"/>

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.)
Comment 2 Tomas Zezula 2011-03-17 15:23:20 UTC
I am afraid it's impossible to support excludes without empty source path.
Comment 3 Jesse Glick 2011-03-17 15:26:16 UTC
Right. So either

1. Use a different project type (designed for use in modules anyway); or

2. Add the snippet to your build.xml.
Comment 4 Jesse Glick 2011-03-30 16:38:12 UTC
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.).
Comment 5 Tomas Zezula 2011-03-30 16:47:31 UTC
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?
Comment 6 Jesse Glick 2011-03-30 17:52:52 UTC
Yes, that is a good summary.
Comment 7 Tomas Zezula 2012-06-04 19:11:22 UTC
*** Bug 200090 has been marked as a duplicate of this bug. ***
Comment 8 Martin Balin 2016-07-07 07:17:37 UTC
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