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.
Environment: jdk8-u40, grails 2.5.0, Netbeans 8.0.2 Clone the git repository found at https://github.com/Richard-Cranium/grails-petclinic.git and checkout branch grails-2.5.0. Open the grails project in Netbeans. Resolve the plugins and then compile the project. Open the Target folder in the project, then the work.plugins.tomcat-7.0.55.2.src.java.org.grails.plugins.tomcat folder, and then the TomcatKillSwitch.java file. You should immediately see the errors indicated for the first two import statements. After a period of time, you will also see that the package statement will be marked as an error. I believe this is an indicator of issues with the correct handling of grails plugins. I have several work-related grails projects that have similar issues but I cannot use them as examples due to intellectual property issues.
I'm requesting a waiver for this bug while it's evaluated. The 'Target' folder shouldn't appear in the workspace tree as the classes there are generated automatically by the build and thus shouldn't be editable. Do other effects occur that you believe may be connected with this? At the moment I'm inclined to believe that this should have a lowered priority - P3: http://wiki.netbeans.org/BugPriorityGuidelines
Bug waiver for 8.1 approved.
(In reply to bruno.flavio from comment #1) > I'm requesting a waiver for this bug while it's evaluated. > > The 'Target' folder shouldn't appear in the workspace tree as the classes > there are generated automatically by the build and thus shouldn't be > editable. > > Do other effects occur that you believe may be connected with this? > > At the moment I'm inclined to believe that this should have a lowered > priority - P3: http://wiki.netbeans.org/BugPriorityGuidelines Grails support in Netbeans is so horrible that it's difficult to tell what causes what problem. Simply removing the target folder won't solve the stated issue since looking for the declaration of a method defined in a plugin will take you the source file in the target folder. In terms of the title, here's an easy one: Use the same example project or any other grails 2.x.x project. (I haven't tested against grails 3.x.x yet.) If you are using this one, open the service org.grails.samples.PetclinicService. There's already a comment in that file... // Petcontroller Type a period at the end of Pecontroller and don't hit the space bar or return... // Petcontroller. Even though you are in a comment, you'll get a popup for forist and inst for some reason. I can't think of a reason to provide code completion in the middle of a comment; I've never seen that while working on a java project in Netbeans. In a grails context, every service has a grailsApplication attribute which contains information about your configuration that's a mashup of the stuff found in your configuration folder. Netbeans knows nothing of this, other than it looks like some generic groovy object instance. Netbeans also doesn't know anything about the logger that's injected into every service, controller, and domain object. While that doesn't effect parsing as such, it does mean than any provided completion for those is practically useless. Netbeans does recognize domain classes and provides a large subset of the domain class injected methods. I don't expect Netbeans to show every possible dynamic query, but the methods that I would expect to see such as save() and withCriteria() are there. Of course, since any random plugin can inject random attributes into any service, controller, or domain class, I'm not sure how you'd handle those issues. IntelliJ manages to do it somehow, but I'm pretty sure they get paid to work on that.