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 270270 - IDE shows FALSE Syntax errors for JSR 330 (Dagger 2) generated classes
Summary: IDE shows FALSE Syntax errors for JSR 330 (Dagger 2) generated classes
Status: NEW
Alias: None
Product: ide
Classification: Unclassified
Component: UI (show other bugs)
Version: 8.2
Hardware: PC Linux
: P3 normal with 1 vote (vote)
Assignee: issues@ide
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-01 11:54 UTC by aplatypus
Modified: 2017-10-13 14:21 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
IDE log (175.28 KB, text/plain)
2017-04-01 11:54 UTC, aplatypus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description aplatypus 2017-04-01 11:54:40 UTC
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();
    }
}
Comment 1 aplatypus 2017-04-01 11:54:45 UTC
Created attachment 163998 [details]
IDE log
Comment 2 quaternion2 2017-06-03 01:33:32 UTC
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.
Comment 3 aplatypus 2017-10-13 14:21:03 UTC
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?