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.
I would like to have enabled 'Run file' actions on .groovy sources. Currently it is not possible, because .java is hardcoded in project action providers. I tried to create LookupMerger for ActionProvider but I had to copy a lot of code and wasn't able to implement invokeAction cleanly, as I don't have access to project internals. What would be the best way to solve this? I am already implementing VirtualSourceProvider from java.source module to ensure that Java editor is aware of groovy files - in ideal world I would expect this contract to be enough to enable Run actions, but projects are unaware of that interface, I know. Should we introduce new SPI for this? Any ideas? I think this is pretty important for 6.5 and not just for Groovy, but also for Scala I guess.
I think the more general issue is the desire to add portions of an ActionProvider implementation from outside the project type (or even support file-sensitive actions on files outside any project). *** This issue has been marked as a duplicate of 102081 ***
I am not sure if this is really duplicate of 102081. What I wanted to say is that I don't want to implement all what is done in J2SEActionProvider. I would like sources producing .class files to be treated almost exactly as .java files.
Groovy may be run from the interpreter, in which case the AP impl would indeed be different. Anyway this will be heavily affected by http://wiki.netbeans.org/CompileOnSave so you should really synchronize with that.
The Compile On Save will affect the groovy plugin, the COS will need to be disabled when there is a groovy file in the source root. If I understand to Martin, he complains about the complexity of the needed code to implement his version of ActionProvider which is de facto J2SEProjectActionProvider without check that file.getExt().equals(java). Right?
Exactly.
But the existing Ant targets will not handle compiling Groovy before the run anyway. You would need a different impl. Since Groovy can be interpreted, I think it would be simplest to just launch the Groovy interpreter directly with the correct arguments.
(using, for example, the extexecution API)
I already have extender which wraps javac into groovyc and works nicely (sure COS is problem, but as Tomas pointed, it could be disabled). This way I have nice integration Java->Groovy and Groovy->Java with joint compilation. I am not sure I would get that in interpreter mode. And also performance could be a problem? I don't see a strong reason do things differently for Java and Groovy. And then - everything is already implemented in project action provider and it's lots of code that I don't want to invent again.
Up to Tomáš how he wants to support it. Implementing a simple AP for RUN_SINGLE on *.groovy would only be a few lines of code, but if you are already overriding the Ant script to handle both languages then it would make sense to change the existing AP to accept anything for which a VirtualSourceProvider is registered.
Martin has already overridden several Ant script targets. It was the only way how to support the use case when a java source accesses a groovy defined type. The suggested solution with VirtualSourceProvider will probably work fine, the only thing is that I want to give the VirtualSourceProvider as a friend API, at least in NB 6.5. I'm afraid of giving the interface as a public API before the GSF will be finished and the copied code from retouche will be eliminated. Merging the gsf with retouche may require a change of this interface.
Not sure if this is still valid, and if so, whether it would use issue #102081.