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.
Summary: | Enable Run file category actions on non-java sources | ||
---|---|---|---|
Product: | java | Reporter: | martin_adamek <martin_adamek> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | REOPENED --- | ||
Severity: | blocker | CC: | jglick, mjanicek, tzezula |
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
martin_adamek
2008-06-09 15:54:30 UTC
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. |