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.
In a Maven based project where either Groovy and Java is used, running a Groovy script with the "Run file" menu item of the context menu is not possible, since it is mapped to the same action as the "Run file" menu item of Java classes. In either cases the "Run file via main()" action of the Maven project is called. There should be another action like "Run groovy script" or something similar. Maybe it could be solved if 'Custom actions' could have a keyboard shortcut.
-> groovy, that's where the mapping for groovy files should reside (unless something in core maven prohibits this from happening, then reassign back please)
What version of NetBeans are you using? I've just tried to create simple Java SE project with one groovy script and it can be run without any problem, so it seems to be working in the latest development version.
I'm using NetBeans 7.3 beta. My project is a Maven based project with jar packaging. Actually it's a vert.x (http://vertx.io) module. The project contains Java classes and Groovy scripts. Both are verticles (a term that vert.x uses). When I press Shift-F6 on a Java class, the default project action is called: "Run file via main()". If you define it in nbactions.xml, it looks like this: <action> <actionName>run.single.main</actionName> <goals> <goal>process-classes</goal> <goal>org.codehaus.mojo:exec-maven-plugin:1.2.1:exec</goal> </goals> <properties> <exec.args>-classpath %classpath ${packageClassName}</exec.args> <exec.executable>java</exec.executable> <exec.classpathScope>${classPathScope}</exec.classpathScope> </properties> </action> It can be seen, that this action can only run Java classes, because the executable is "java". The problem is that if I press Shift-F6 on a Groovy script (not class!), the same action is called and of course it won't run. The following is shown in the output window: run: Error: Could not find or load main class MyGroovyScript Java Result: 1 The groovy scripts are in the /src/main/groovy directory.
Would it be possible to attach your project? Or if not, could you narrow the problem to the minimal case and create simple project for it? The problem might be related to your configuration which is why I'm not able to reproduce with a clean project.
Created attachment 125772 [details] Example Maven project to reproduce the problem I created and attached a Maven project that has a Java class and two Groovy scripts. The only dependency of the project is groovy-all-2.0.0. The Java class can be run with Shift-F6, but running any of the Groovy scripts with Shift-F6 fails.
As far as I understand maven-compiler-plugin [1] is using javac by default. If you need to use some specific compiler (as in your case where you need to compile java & groovy sources), you have to say what compiler should be used. If you change your plugin registration to this: <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-eclipse-compiler</artifactId> <version>2.6.0-01</version> </dependency> </dependencies> <configuration> <compilerId>groovy-eclipse-compiler</compilerId> </configuration> </plugin> <plugin> <artifactId>groovy-eclipse-compiler</artifactId> <groupId>org.codehaus.groovy</groupId> <version>2.6.0-01</version> <extensions>true</extensions> </plugin> ..it compiles and run your scripts without problem. [1] http://maven.apache.org/plugins/maven-compiler-plugin/
Closing as INVALID as the issue is in wrong configuration.
Thanks. Now it's working. But there is a still a problem. 0.) Make sure compile on save is enabled for both application and test execution 1.) Do a clean-build on the project 2.) Run any of the Groovy scripts with SHIFT-F6, now it runs 3.) Change and save the Groovy script 4.) Run the changed Groovy script: now it does nothing, though it prints out "BUILD SUCCESSFUL" 5.) Invoke build on project and try running the Groovy script again: still nothing (same as point 4) 6.) Invoke clean-build on the project and try running the Groovy script: now it's running perfectly Am I doing something wrong or is it a bug? Shall I file a separate issue for this?
(In reply to comment #8) > Thanks. Now it's working. But there is a still a problem. > > 0.) Make sure compile on save is enabled for both application and test > execution > 1.) Do a clean-build on the project > 2.) Run any of the Groovy scripts with SHIFT-F6, now it runs > 3.) Change and save the Groovy script > 4.) Run the changed Groovy script: now it does nothing, though it prints out > "BUILD SUCCESSFUL" > 5.) Invoke build on project and try running the Groovy script again: still > nothing (same as point 4) > 6.) Invoke clean-build on the project and try running the Groovy script: now > it's running perfectly > > Am I doing something wrong or is it a bug? Shall I file a separate issue for > this? Nope, that's a valid issue caused by CoS. In Ant based project when someone creates new Groovy class/script the CoS is disabled for the project and thus it can be run easily. It isn't a nicest solution but at least it works. I can do the same for Maven projects, but don't know about better solution. Milosi what do you think?
(In reply to comment #9) > (In reply to comment #8) > > Thanks. Now it's working. But there is a still a problem. > > > > 0.) Make sure compile on save is enabled for both application and test > > execution > > 1.) Do a clean-build on the project > > 2.) Run any of the Groovy scripts with SHIFT-F6, now it runs > > 3.) Change and save the Groovy script > > 4.) Run the changed Groovy script: now it does nothing, though it prints out > > "BUILD SUCCESSFUL" > > 5.) Invoke build on project and try running the Groovy script again: still > > nothing (same as point 4) > > 6.) Invoke clean-build on the project and try running the Groovy script: now > > it's running perfectly > > > > Am I doing something wrong or is it a bug? Shall I file a separate issue for > > this? > > Nope, that's a valid issue caused by CoS. In Ant based project when someone > creates new Groovy class/script the CoS is disabled for the project and thus it > can be run easily. It isn't a nicest solution but at least it works. > I can do the same for Maven projects, but don't know about better solution. > Milosi what do you think? for 7.3 I've disabled CoS by default for all project types, with the exception of war,ejb,ear packagings which you and dkonecny explicitly required. Is there any ui associated with disabling CoS when groovy files are around? There definitely should be, maybe a ProjectProblemProvider recognizing that problem with a resolution that disables it.
> > Nope, that's a valid issue caused by CoS. In Ant based project when someone > > creates new Groovy class/script the CoS is disabled for the project and thus it > > can be run easily. It isn't a nicest solution but at least it works. > > I can do the same for Maven projects, but don't know about better solution. > > Milosi what do you think? > > for 7.3 I've disabled CoS by default for all project types, with the exception > of war,ejb,ear packagings which you and dkonecny explicitly required. Is there > any ui associated with disabling CoS when groovy files are around? Currently not. > There definitely should be, maybe a ProjectProblemProvider recognizing that > problem with a resolution that disables it. Yep, that's sounds reasonable. I'm on it.
API for CoS skipping done by Milos in: core-main 1f01821168ce I'll make the groovy implementation once it gets propageted to the web-main repository. Thanks, Milosi!
Created attachment 126126 [details] Implementation of the CoSSkipper + one more CoS API class for cleaning class files Adding patch with groovy implementation of the CompileOnSaveSkipper + adding one more friend API class called CompileOnSaveClassCleaner which is necessary for recompiling specific class files (the one corresponding to groovy files in this case) + it's implementation for groovy. Milosi could you please take a look and make a fast review of it?
After offline discussion with Milos a Honza, reassigning the issue.
I'm increasing the priority to P2 as this really need to be fix for 7.3. There are several possible ways how to do that. 1. Ideally the fix will be provided by the CoS infrastructure itself (and by Honza:)). 2. Alternatively if point 1 would be too complicated, we still can use my solution from comment 13, which isn't a nicest solution but still better than current state. 3. Or we can just disable CoS when groovy file is present, but I don't like that idea (that's the way how martin adamek done this few years ago for Ant projects, but from my point of view it just push people away from using groovy support as they can't use CoS for java files with it)..
Created attachment 126829 [details] A sketch of a possible fix Could you please try this patch to see if it solves the problem? Thanks.
(In reply to comment #16) > Created attachment 126829 [details] > A sketch of a possible fix > > Could you please try this patch to see if it solves the problem? Thanks. I've tried some basic scenarios and it seems to work perfectly ;)
Hi all, Will the COSSkipper be available to all projects or only for Maven based ones? I'm asking because I also have a need to not have Netbeans compile my Groovy classes as I've implemented my own way to compile Groovy classes through a custom classloader which uses GroovyScriptEngine underneath. This is for a web app where I use the GroovyScriptEngine to compile classes on the fly and recompile when changes occur. Currently Netbeans compiles the Groovy classes when I make changes to them which interferes with my custom ClassLoader and GroovyScriptEngine. So having the ability to configure Netbeans to not compile Groovy classes would be a great feature. Kind regards Bob
(In reply to comment #18) > Will the COSSkipper be available to all projects or only for Maven based ones? At the end the COSSkipper won't be used at all. Honza's patch provide much better and generic solution (which is independent on the project type). > I'm asking because I also have a need to not have Netbeans compile my Groovy > classes as I've implemented my own way to compile Groovy classes through a > custom classloader which uses GroovyScriptEngine underneath. This is for a web > app where I use the GroovyScriptEngine to compile classes on the fly and > recompile when changes occur. > > Currently Netbeans compiles the Groovy classes when I make changes to them > which interferes with my custom ClassLoader and GroovyScriptEngine. > > So having the ability to configure Netbeans to not compile Groovy classes would > be a great feature. I'm not sure if your use case is the same as what we have done here. There will be still just one option for CoS but it won't be triggered for groovy files (simply because we don't have that kind of feature implemented for groovy files). Which means we are going to compile groovy files only when someone build the application. Independently on the CoS setting.
The classfiles for the virtual files are not copied into build/classes (or alike): http://hg.netbeans.org/jet-main/rev/8a4dc1826b8d
Integrated into 'main-golden', will be available in build *201211150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8a4dc1826b8d User: Jan Lahoda <jlahoda@netbeans.org> Log: #219787: do not copy classfiles for virtual sources into build/classes or alike.