I have two groovy files (in case you are not familiar with groovy, think of it as a java file).
I have file A.groovy in package test.BI. This file has makes use of a class Master which is in B.groovy which is also in the package test.BI. However this B.groovy also makes use of a class Execution which is in A.groovy.
When I compile A.groovy it errors unable to resolve class Master and when I compile B.groovy it errors unable to resolve class Execution.
Both A.groovy & B.groovy have multiple classes. How can I solve this problem without creating one file for each class.
In IntelliJ IDEA, invoke Make (Ctrl+F9), or Compile (Ctrl+Shift+F9) on just these two files (after selecting them both in the Project View).
Related
I want to simply create a reusable "library" for all my future projects that I'm going to be doing in Haxe. I understand there aren't library projects in Haxe, but rather you would just have a collection of source files somewhere and import them as needed. Right?
I've created a new project using Flambe (a Haxe framework) and opened it in the FlashDevelop IDE. It compiles and runs fine.
Now I want to include my library, so I go into the Project Properties under the "Classpaths" tab and set the relative path to my library. It shows up correctly in the "References", and even has the proper code completion when I type "import ...", yet when I compile it fails on the import line stating: 'Class not found : mlg.Engine'
(mlg being the package, and Engine being the class/type)
Is there anything I'm missing?
I think (i may be wrong) that flashdevelop "references" are just autocompletion and not actually passed to the compiler.
I'm not sure what's the "right" way to do it, but I can tell you what I've done (I made a few helper classes for flambe too :P): I simply created a "fake" haxelib, I created HaxeToolkit/haxe/lib/[name]/git, and in [name] i created a .current file that contains "git".
Then on flashdevelop you have to add it as a library (Project settings -> Compiler options -> Libraries).
Note: there are probably other/better ways to do it.
A simple Groovy Class in a package com.something
package com.something
class A {
}
Another class in the same package
package com.something
class B {
def variable=new A() //DOES NOT WORK TILL I EXPLICITLY say "import com.something.A"
}
Why Class B is not able to access class A, even though they both are in the same package?
Sadly the question does not really have the needed information to answer it completely. But I can tell the following. If you make a directory ./com/something/ and out A.groovy and B.groovy in there and then compile them using the commandline groovyc ./com/something/A.groovy ./com/something/B.groovy, then this must work. So far the directory is not really important, but that changes if you change to groovyc ./com/something/B.groovy, because now groovyc has to "discover" A.groovy and requires the correct directory structure for this.
Now, how the ant, gradle and maven version of groovyc normally work is by supplying a complete list of sources. If this is not done, compilation may fail. But if the root directories for A and B are different and you do not give both to the compiler, then it will surely fail.
I cannot know if that is the reason, so I want this answer more understood as a pointer to what might be wrong. Hope this helps
I have IntelliJ 12 and some groovy code (along with a pile of java code) in a project.
In intelliJ, i can see class A's import of some groovy code, and i have also included the library that has that code.
However, while the package itself is in one colour (for the import), the actual class being imported is in red, which implies an issue of some sort. Hovering the mouse over it reveals no issue though.
When i run a "make" or a "rebuild project" is where the problems start - i get
Groovyc: unable to resolve class com.blah.blah.blah.A
How can i resolve this?
Currently, my project setup is like so:
Under "Libraries" in (Project Structure -> Project Settings -> Libraries) I have:
the jar file with all the groovy code
the src jar file with all the groovy code
In the "Modules" section i have the - well, i don't know what to call it, the column isn't labelled - the library name from the libraries section associated with the src and class files, and the little "export" button beside it is ticked.
Incidentally, opening the class in intelliJ never shows the source code, which given the source is included struck me as weird.
Is there anything else I should need to do?
I've worked this one out, but if anybody knows why groovy cannot be in the "Resource Patterns" list and wants an upvote, do chime in
Oh, right.
I removed the !?*.groovy entry from the list of, um, entries in the File : Settings -> Compiler -> Resource Patterns thingy.
It doesn't seem to matter if "use external build" is on or off for this, but the !?*.groovy; entry cannot be there.
I wonder if anybody knows why?
I had the same problem and had to Add Framework Support and add Groovy to the project to get round this problem.
I created the project using gradle.
I just got your question in my Google results as I had a similar issue. My problem was that I was able to get the groovy code in my IntelliJ 12 project to compile ok, but it wasn't getting wired in properly when I tried to run unit tests within the IDE.
After some investigation, I uncovered that groovy and logback libraries were all set up in the project to be available in the runtime stage of the Maven build of the project, but that resulted in them not being available in the test stage. To fix this, I ended up manually updating the groovy-all and the logback libraries scope from runtime to provided under File->Project Structure->Modules->Dependencies. This allowed me to both compile and test within the IDE while including the Groovy modules as well as the Java modules.
Perhaps you had something similar going on in your project?
Six years later, I also just got this question near the top of my search results.
In my project my Unable to load class 'groovy.text.SimpleTemplateEngine' problem was actually due to a codenarc issue. I was able to resolve the issue by adding the following to build.gradle:
// codenarc version issue work-around
configurations.codenarc {
resolutionStrategy.eachDependency { DependencyResolveDetails d ->
if (d.requested.group == 'org.codehaus.groovy') {
d.useVersion '2.4.7'
}
}
}
I know that since Groovy 2.0 there are annotations for static compilation.
However it's ease to omit such annotation by accident and still run into troubles.
Is there any way to achieve the opposite compiler behaviour, like compile static all project files by default and compile dynamic only files chosen by purpose with some kind #CompileDynamic annotation for example?
I have found some (I believe recently introduced) feature which allows doing so with Gradle.
In build.gradle file for the project containing groovy sources we need to add following lines:
compileGroovy {
configure(groovyOptions) {
configurationScript = file("$rootDir/config/groovy/compiler-config.groovy")
}
}
or compileTestGroovy { ... for applying the same to test sources. Keep in mind that neither static compilation nor type checking works well with Spock Framework though. Spock by its nature utilizes dynamic 'groovyness' a lot.
Then on a root of the project create folder config/groovy/ and a file named compiler-config.groovy within. The content of the file is as follows:
import groovy.transform.CompileStatic
withConfig(configuration) {
ast(CompileStatic)
}
Obviously path and name of the configurationScript may vary and it's up to you. It shouldn't rather go to the same src/main/groovy though as it would be mixing totally separate concerns.
The same may be done with groovy.transform.TypeChecked or any other annotation, of course.
To reverse applied behaviour on certain classes or methods then #CompileDynamic annotation or #TypeChecked(TypeCheckingMode.SKIP) respectively may be used.
I'm not sure how to achieve the same when no Gradle is in use as build tool. I may update this answer in the future with such info though.
Not at this time, but there is an open Jira issue here you can follow to watch progress for this feature
There was also a discussion about methods for doing this on the Groovy developers list
Along with many class resolution errors, my project suddenly started to display this error on the package:
The type groovy.lang.MetaClass cannot be resolved. It is indirectly referenced from required .class files
- The type groovy.lang.GroovyObject cannot be resolved. It is indirectly referenced from required .class
files
I also noted that the unit tests all are failing to compile and display this error on the TestFor annotation:
- Groovy:class TestFor is not an annotation in #TestFor
- Groovy:unable to resolve class TestFor , unable to find class for
annotation
I have tried to clean the project then to refresh dependencies but still no joy. I quite STS and restarted and tried the clean/refresh as well.
I do get a compile error on one of my .groovy files which complain about undefined classes--but I have added the jar defining those classes to my lib folder and do not see any errors on import of the class.
Any suggestions? Do I have to rebuild the entire project?
It turns out that an undefined symbol that stopped the compile had this result. I wasn't familiar with how STS/Eclipse handles a failure to resolve a class and had expected the class path to have been defined before any actual compiles were completed.
So the answer is to look in the error log for STS, determine if one of my classes are missing, and resolve that first before rabbit-holing down a path like this.