I'm using Groovy for a calculation engine DSL and really like the support we now have in Eclipse with STS and the Groovy-Eclipse plug-in (I'm on STS 2.8.0M2 with latest milestone of Groovy-Eclipse 2.5.2).
One issue I have is I don't know how to get the Groovy editor to 'know' the automatic imports I've added to my script runner, meaning Eclipse gives me a whole bunch of false errors. If you use the Groovy class loader, you can add additional import for 'free', so you avoid needing to do imports in your script.
I've had a play with the DSLD support in Groovy-Eclipse (which can be used to add auto-completion support) but it's not obvious to me that this is something I could do with it - I don't find the DSLD documentation the simplest to follow.
The inferencing settings for Groovy in Eclipse didn't look like the right thing either.
For example:
def result = new CalculationResult()
gives me an error on the CalculationResult class as it's not imported, but the script will execute correctly in my environment because of the customized imports on the Groovy class loader. I'm using the standard import customization provided by Groovy, for example:
import org.codehaus.groovy.control.customizers.ImportCustomizer
import org.codehaus.groovy.control.CompilerConfiguration
def importCustomizer = new ImportCustomizer()
importCustomizer.addImport 'CalculationResult', 'ch.hedgesphere.core.type.CalculationResult'
def configuration = new CompilerConfiguration()
configuration.addCompilationCustomizers(importCustomizer)
...
Any pointers appreciated.
This seems to be in their bugtracker as coming in the 2.6 release of the plugin.
But the comment from Andrew Eisenberg doesn't bode well:
Unfortunately, this is not something that DSLDs can do. Since a
missing import could mean compile errors, we would need a way to
augment the compiler lookup for this. There might be a way to specify
this information inside of a DSLD, but that would mean hooking into
DSLDs in a very different way. More likely, this will have to be
specified through an Eclipse plugin (like the gradle tooling).
Another possibility is that we can ensure that certain kinds of AST
Transforms are applied during a reconcile and so the editor would just
"magically" know about these extra imports. We will have to look into
the feasibility of this, however.
Still, maybe a vote on that issue wouldn't go amiss?
Related
My eclipse is configured so that when I save the java source file, it automatically inserts the missing import declarations. Except when the reference is ambiguous. Fpr instance, the most annoying ambiguity is with List<T> - both java.util and java.awt declare it. Here eclipse demands manual resolution.
I was wondering if it was possible to configure somewhere that whenever List<T> is used then java.util should be imported. Or alternatively, since I am not using java.awt, I could just remove it from the list of possible suggestions.
Any ideas?
Thanks.
This sounds like a possible duplicate of Exclude packages from Eclipse's organize imports.
Basically, you want to change your Type Filters preference to exclude java.awt.* packages. Keep in mind that doing so will make things harder/confusing if you ever try to write AWT/Swing code.
One thing that pops into my mind is altering the class template in the preferences to include the line:
import java.util.List
Unless you are going to use the AWT version of a List, or care about unused import statements, that should solve this annoying issue ..
Manually invoke Organize Imports and it will ask you when an ambiguity is found.
I use eclipse as my scala ide. And I know that in java I can use short cut by content assistent to import classes. So I do not need type in the whole class name. Just need to type the first several characters.
But in scala, I can not import classes automatically. Do I need to do some set up or it is just because scala plugin do not support this.
Ctrl + 1
on symbol works for me :)
There is Scala IDE for Eclipse however it is not very mature these days, however improving day by day. As far as I remember it can import automatically, or you can use Eclipse global fix import hotkey ctrl+shift+o.
I'm trying to work through groovy's Implementing Local AST Transformations tutorial, but whenever I clean my project I get this error in each file that has the #WithLogging annotation in it:
Groovy:Could not find class for Transformation Processor AC.LoggingASTTransformation declared by AC.WithLogging
So you have a package named "AC" that contains both "WithLogging.groovy" and "LoggingASTTransformation.groovy" classes? Does it also contain any classes that implement the "WithLogging" interface?
If so, I'd suggest you move the class(es) that use your annotation to a location outside of the annotation defining package (the default will suffice, for diagnostic purposes) - Order of compilation matters with transformations. See this post on the groovy users mailing list for more on that.
Also try changing the annotation from #WithLogging to #AC.WithLogging.
As far as cleaning with Eclipse is concerned, I had a similar issue and found that I had to make a trivial modification after a clean to any file that contained my annotation. IE, add a space somewhere. Then save the file. This should rebuild everything properly.
It is possible to implement the refactoring by using Eclipse library (JDT,LTK) without involving of the wizards. I would like to get benefit from refactoring feature of eclipse but I wan't to provide input for refactoring by other ways (that is not entering in the wizard) such as reading from file, etc.
If possible , Please suggest me how
You can find a sample in the JDT's SurroundWithTryCatchAction (eliding a lot of detail):
SurroundWithTryCatchRefactoring refactoring= SurroundWithTryCatchRefactoring.create(cu, selection);
Change change= refactoring.createChange(new NullProgressMonitor());
PerformChangeOperation op= new PerformChangeOperation(change);
WorkbenchRunnableAdapter adapter= new WorkbenchRunnableAdapter(op);
PlatformUI.getWorkbench().getProgressService().runInUI(
new BusyIndicatorRunnableContext(), adapter, adapter.getSchedulingRule());
The refactoring is set up entirely non-interactively through the create-helper.
Basically I can't even import Groovy classes in a regular GWT EntryPoint:
import com.google.gwt.core.client.EntryPoint; // OK
import groovy.lang.Binding; // NOT OK
import groovy.util.GroovyScriptEngine; // NOT OK
Intellij 8.0's inspector keeps telling me this:
Class 'groovy.lang.Binding' is not present in JRE Emulation Library so it cannot be used in client code
Class 'groovy.util.GroovyScriptEngine' is not present in JRE Emulation Library so it cannot be used in client code
Obviously I end up having problems at runtime as well:
[ERROR] Line 11: No source code is available for type groovy.util.GroovyScriptEngine; did you forget to inherit a required module?
[ERROR] Line 12: No source code is available for type groovy.lang.Binding; did you forget to inherit a required module?
I've checked several times my module's dependencies, and groovy-all-1.6.1.jar is correctly defined in there. I'm probably missing something elsewhere...
Any idea?
Attempting to use Groovy makes no sense as the Gwt compiler only understands the Java language syntax along it it's subset of Java libraries. The compiler works on source not byte code. One reason includes the magic comments necessary to stash javascript (JSNI). The compiler is actually scanning the source path for *.java not *.class files.
Read the doco fir a more in depth understanding.
In some sense it would be pretty cool to have a groovy language gwt.
But then why go from one dynamic language to another? The point of gwt I thought was to get static typing and easy debugging of java.