Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 136835 - Enable Run file category actions on non-java sources
Enable Run file category actions on non-java sources
Status: REOPENED
Product: java
Classification: Unclassified
Component: Project
5.x
All All
: P2 (vote)
: TBD
Assigned To: Tomas Zezula
issues@java
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-09 15:54 UTC by martin_adamek
Modified: 2012-05-14 14:57 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description martin_adamek 2008-06-09 15:54:30 UTC
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.
Comment 1 Jesse Glick 2008-06-10 00:22:47 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 ***
Comment 2 martin_adamek 2008-06-10 12:08:57 UTC
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. 
Comment 3 Jesse Glick 2008-06-10 12:21:36 UTC
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.
Comment 4 Tomas Zezula 2008-06-10 12:57:51 UTC
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?
Comment 5 martin_adamek 2008-06-10 13:00:51 UTC
Exactly.
Comment 6 Jesse Glick 2008-06-10 13:02:44 UTC
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.
Comment 7 Jesse Glick 2008-06-10 13:04:46 UTC
(using, for example, the extexecution API)
Comment 8 martin_adamek 2008-06-10 14:32:57 UTC
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.
Comment 9 Jesse Glick 2008-06-10 16:21:42 UTC
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.
Comment 10 Tomas Zezula 2008-06-10 16:35:09 UTC
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.
 
Comment 11 Jesse Glick 2009-07-16 18:48:04 UTC
Not sure if this is still valid, and if so, whether it would use issue #102081.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo