I want migrate Geb functional tests from 1.3.7 to 3.1.9. Tried to create a new plain test with grails create-functional-test in IntelliJ an via console. Both failed with Command not found create-functional-test.
I created a new application with grails create-app and tried again grails create-functional-test, it works as expected.
Compared and improved all Grails dependencies in build.gradle.
Any ideas how i can fix this issue?
EDIT:
If i uncomment this line: //compile "org.grails.plugins:geb:0.13.1" in build.gradle File it is possible to create a Testfile but of course Grails does not know the GebSpec class.
EDIT 2: I solved it!
The old Plugin, see above, caused the problem. I deleted the dependency and reimported my apllication, know it works.
Related
I've been unable to create/import a Grails 2.4.3 project with IntelliJ 13.1.4. For example, when I create a new module, choose Grails, then click the create button (highlighted below) and choose the location where Grails 2.4.3 is installed, the project is not created correctly (I get a module with just a /src directory instead of a Grails project) and Grails 2.4.3 is not added to the list of Global Libraries. I don't have this problem with any earlier version of Grails.
I have used Grails 2.4.2 with Intellij 13.1.4 successfully. What I did is create the application with the grails create-app command and then do a File / Import Project in Intellij. Give that a try.
As an alternative solution to the IntelliJ 13.1.4 and Grails 2.4.3 bug you can:
grails create app <app-name>
cd app-name
grails integrate-with --intellij
This configured the project correctly for me with just minor tweaks to SDK and application server. This is a minor twist on the work around described above.
See grails doc here
I had the same problem with IntelliJ 13.1.4 and Grails 2.4.3, which i just downloaded.
After using the grails create-app command from the command line i had to import the project, by "create from existing sources" (point to the new top level folder), "Configure SDK" (to set for the Grails 2.4.3) and finally edit the run configuration. In a second test run with a new test project i did not have too configure the run config.
Then the Grails libs for the were downloaded and the basic app ran. Also the Grails specific option in the Intellij "Tools2 section were suddenly available.
So the given answer by Joe is the way to setup a new Grails project but the IDE should be fixed anyways.
It is not consistent. After several tries I can get some applications to work but it does not seem to be automatic. I think I am going to go back to Grails 2.4.2 until this is resolved within Intellij 13.1.4.
In the screenshot above, there are options for groovy/grails/griffon, and so far the alternative offered was command-line. Try choosing groovy option within intelliJ.
We are using IDEA 13.1.4 with grails 1.3.7 and grails 2.2.1(diff projects) and saw the same issue. It appears this is an intelliJ issue and not so much the grails version, so reverting your grails won't gain you anything. Choosing groovy, you should see a prompt for grails directory structure. This does work if you are presented with this option. Seeing inconsistencies here. Thanks to all for posting your workarounds; never hurts to have multiple approaches.
-Duane
I'm using Groovy/Grails Tool Suite 3.2.0.RELEASE, Grails 2.2.2 and Groovy Compiler 2.0.
When I try to run an app I get the following error:
Error executing script RunApp: org/apache/ivy/plugins/resolver/ChainResolver
Can anyone help me?
Best regards.
UPDATED
Check your index.gsp file and remove the line showing the Groovy version.
org.codehaus.groovy.runtime.InvokerHelper.getVersion has changed to
GroovySystem.getVersion in newer Groovy builds bundled in Grails.
Initially I would have said that you upgraded projects from previous Grails versions.
Install a new version of Grails
Update the application.properties file
Run grails upgrade
Create a new blank project and compare the BuildConfig.groovy to see if a dependency needs upgrading.
I think that the index.gsp modification will do it. If not, please add details about the actions that you're taking and when the error occurs(stacktrace will also be needed).
I've modified my app to be a grails plugin, which I'm going to include in client-specific applications and customize some bits and pieces.
To test the whole thing, I've included the plugin as inline in the BuildConfig of a test application [bare application created using grails commandline].
grails.plugin.location."engine-plugin"="../../engine-plugin"
I did not install the plugin itself, I did not add a thing into plugins part of the BuildConfig in my app.
Now, in the BuildConfig of the plugin, I've included all of the plugins I require in my engine:
compile (
":asynchronous-mail:0.6",
":famfamfam:1.0.1",
":google-visualization:0.5.3",
":gsp-arse:1.3",
":jquery:1.8.0",
":jquery-ui:1.8.15",
":mail:1.0",
":navigation:1.3.2",
":prototype:1.0",
":quartz2:0.2.3",
":rendering:0.4.3",
":spring-security-core:1.2.7.3",
":spring-security-ui:0.2"
)
Unfortunately, when I run grails run-app in my test app, it can't resolve some classes:
4: unable to resolve class grails.plugins.springsecurity.Secured
# line 4, column 1.
import grails.plugins.springsecurity.Secured
^
Obviously, that's because my app can't see the spring-security-core or it's dependencies.
I've tried changing the scope in my plugin's BuildConfig from compile to build, but that changes nothing. I've tried adding export=true to it - nothing.
Any tips on how to proceed with this?
Thanks
EDIT:
getting the same error when using the packaged plugin instead of inline :/
I'm using STS latest version (2.7) and latest grails as well. After I created a freshly grails project in STS it freezes in the updating grails dependencies for a long time and it comes out as a timeout error. And it follows by some GroovyObject error, but the project still runs fine in command-line. So I ditched STS for refreshing dependencies, and I included the dependency in BuildConfig.groovy and use grails compile but I still got ClassNotFound error when compiling, it's like grails didn't pick up the Ivy CLASSPATH. So, I'm thinking of changing it to Maven to resolve any dependencies.
My question would be which one is better and integrated seamlessly in STS or Eclipse?, but I still want to use grails commands, not maven.
If your project is just a grails project - use grails dependencies.
I've experience with mavenized grails project, and plain grails project. First is good when you have multimodule project, and only one of them is grails module. At this case you'll lost all grails commands, you need to use commands like mvn grails:run-app and it's complicated thing to pass arguments into commands :(
I'm having issues getting something which seems very basic running with Grails. I want to call grails commands from an Ant script - Grails provides a Grails task to achieve this. I have defined the Grails taskdef and classpaths as per the docs however, no matter what command I call I get the same error...
grails-compile:
[grails] Resolving dependencies...
[grails] Dependencies resolved in 1192ms.
BUILD FAILED
/java/grailstest/build.xml:22: Unable to start Grails: java.lang.reflect.InvocationTargetException
Even when I create a new Grails app using 'grails create-app' and then run the integrate ant command 'grails integrate-with --ant' to generate a default build.xml, I get the same error when running any of the tasks in the generated build.xml.
I've tested this with Grails 1.3.1, 1.3.4 and 1.3.5 and am getting the same error.
Has anyone else encountered this problem? There must be something stupid I'm doing wrong or this would never have made it out the door of the Grails factory... ;)
I forgot to mention that I am using Ant version 1.8.1. I have just discovered that switching back to Ant 1.7.1 'solves' this problem but this is not really ideal as I need 1.8.1 for other build tasks. I'll submit a bug on the Grails issue tracker as it seems a lot of people are having the same problem.
I've just found the same issue. It seems that Ant 1.8 is not supported yet (but Ant 1.7 is), see GRAILS-6897. Some users have complained that the documentation does not state it strictly.