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.
Product Version = NetBeans IDE 8.2 (Build 201609300101) Operating System = Linux version 4.4.0-70-generic running on amd64 Java; VM; Vendor = 1.8.0_121 Runtime = Java HotSpot(TM) 64-Bit Server VM 25.121-b13 Reproducibility: Happens every time STEPS: * Load the project file for Part one from "A Friendly Introduction to Dagger 2: Part 1" [1] - https://medium.com/@isoron/a-friendly-introduction-to-dagger-2-part-1 * Build project with Netbeans or with Gradle on the command line * File builds project OK * Netbeans show Compiler errors on generated class: com.example.DaggerAppComponent * Run the project / program Application * Program works despite the inicated error ACTUAL: * Program works * Netbeash show errors EXPECTED: * Netbeans needs to "find" the class(es) it reports as errors. - I have shown the lines reported as errors below from "Application.java" * None of the IDE/Java editor commands can find the generated code. * trying to fudge the directrories or sourceSets, etc has proven an effective hack to solve the problem * Also when I CTRL-click on "DaggerAppComponent" the editor doesn't "know" to open the generated file. NOTES * The apt plug-in generates code to the build directory * When I attempted to point the sourceSet to those folders, Netbeans more or less ignored stuff under build/ It is quite annoying trying to understand where a bug that is good code is or triple checking seemingly good code because the IDE says the file has a problem. Lots of annotations and packages use generated code. In InteliJ-s IDEA there is a properties panel for handling generated code. I didn't find anything in Netbeans that could help like that. =====[ references ]=============== [1] https://medium.com/@isoron/a-friendly-introduction-to-dagger-2-part-1-dbdf2f3fb17b [2] https://github.com/tbroyer/gradle-apt-plugin =====[ Application.java ]============ package com.example; import javax.inject.*; import dagger.*; import com.example.DaggerAppComponent; // <-- Error here @Component interface AppComponent { WeatherReporter getWeatherReporter(); } public class Application { public static void main(String args[]) { AppComponent component = DaggerAppComponent.create(); // <-- Error here WeatherReporter reporter = component.getWeatherReporter(); reporter.report(); } }
Created attachment 163998 [details] IDE log
Found part of the solution here: https://stackoverflow.com/questions/9847483/why-doesnt-netbeans-ide-see-the-generated-sources In short: ${basedir}/target/generated-sources/FOOBAR where FOOBAR is the name of the plugin (maven). Testing this, renaming ../target/generated-sources/annotations/... to ../target/generated-sources/dagger-compiler/.. has resolved the issue for me. However I'm not certain how to change the output directory, but I suppose that isn't a Netbeans issue. Although I find it interesting that the plugin name matters, it isn't clear to me why that is so? Until I find out how to change the output dir when the project is rebuilt the issue returns.
I found this bug (again) tonight after again bumping against the same problem with the new Gradle 2.4 plugins section. I downloaded this project * https://github.com/griffio/dagger2-example It builds, and runs fine using both Netbeans and gradle on the command line. AND there's 100-s of little read-dots in the project explorer and in a variety of source modules. This project places the generated code in: * src/dagger/java As a gradle project the build directory is where 'target' goes. In other circumstances we found false-syntax errors for WSDL and when we moved the sourceSets to something like: * src/generated/wsdl Things got better. More or less as described in the Stackoverflow explanation. Oh, also for WSDL, the (Ant) tool that did the generation needed to be configured for 'output' -- For example, for: wsdl2java something such as ... wsdl2java { // target directory for generated source code generatedWsdlDir = file( "$projectDir/src/main/generated" ) : } ... was required. BUT . . . (and this is probably 'Why' the (named) plug-in used matters -- Finding that, "generatedWsdlDir" attribute, took some effort because the first plugin we used was (quote) "abandonware" and we had to change to another off-spring plugin; then figure-out how it ought to work. ~sigh~ I reckon the same applies in this case. The actual plugin used may well have an attribute, like the "generatedWsdlDir" attribute. (In reply to quaternion2 from comment #2) > Found part of the solution here: > https://stackoverflow.com/questions/9847483/why-doesnt-netbeans-ide-see-the- > generated-sources > > In short: ${basedir}/target/generated-sources/FOOBAR where FOOBAR is the > name of the plugin (maven). > > Testing this, renaming ../target/generated-sources/annotations/... to > ../target/generated-sources/dagger-compiler/.. has resolved the issue for me. > > However I'm not certain how to change the output directory, but I suppose > that isn't a Netbeans issue. Although I find it interesting that the plugin > name matters, it isn't clear to me why that is so? Until I find out how to I reckon the same applies in this case. The actual plugin used may well have an attribute, like the "generatedWsdlDir" attribute. So the specific plugin can easily alter things like this. > change the output dir when the project is rebuilt the issue returns. With the plugin YOU are using; check the project, gradle.org or whatever for the properties and attributes they implement. UPDATE ... Current configuration is: * Netbeans v8.2 ------------------------------------------------------------ Gradle 4.2 ------------------------------------------------------------ Build time: 2017-09-20 14:48:23 UTC Revision: 5ba503cc17748671c83ce35d7da1cffd6e24dfbd Groovy: 2.4.11 Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015 JVM: 1.8.0_144 (Oracle Corporation 25.144-b01) OS: Linux 4.4.0-96-generic amd64 I still believe Netbeans/the Gradle support can and should be able to interrogate things with outputs, especially for annotation processors, like a AspectJ, Dagger or WSDL, and understand where things ARE doing what they do. Oddly enough JavaFX manages to get compiled without Netbeans worrying where the little @FXML injections were generated. So yea why is this Not a Netbeans problem?