My application uses the following versions:
Geb: 0.9.2
Selenium: 2.26.0
Grails: 2.1
Spock: 0.7
And I'm running on a linux box with the following:
Firefox: 14
Centos: 5.3
I have a grails application and I am using Geb in the functional test phase.
If I'm starting from a clean environment (.grails has been wiped) and I run my tests they all go through fine, geb runs up firefox, does the tests and gives me the report.
However subsequent runs of the functional tests all tests will fail with:
geb.giver.DriverCreationException
which is apparently caused by:
java.lang.NoSuchMethodException
Now if I trash my .grails and run again, the next time the pass fine. Just want to be able to run the tests consistently.
Any help would be greatly appreciated!
Cheers
UPDATE:
Below is the gist of the stack trace (copied by hand so apologies for any typos):
geb.driver.DriverCreationException: failed to create driver from callback 'GebConfig$_run_closure#6f61a3c4'
at geb.driver.CallbackDriverFactory.getDriver(CallbackDriverFactory.groovy:35)
at geb.driver.CalbackDriverFactory.getDriver_closure3(CachingDriverFActory.groovy:80)
...
Caused by: java.lang.NoSuchMethodError: org.apache.http.conn.scheme.Scheme.<init>(Ljava/lang/string;ILorg/apache/http/conn/scheme/SchemeSocketFactory;)V
at org.openqa.selenium.remote.internal.HttpClientFactory.getClientConnectionManager(HttpClientFactory.java:59)
at org.openqa.selenium.remote.internal.HttpClientFactory.<init>(HttpClientFactory.java:48)
at org.openqa.selenium.remote.HttpCommandExecuter.<init>(HttpCommandExecuter.java:118)
...
I had this exact issue in the past. Exactly with HttpDriver classes in the stacktrace and happening on the second run after a clean. It's due to some of your Grails plugins pulling in a conflicting version of HttpClient.
I found that it's usually a plugin that transitively pulls in the release plugin but doesn't exclude it from exporting. The way to find the culprit is to go through all of your installed plugins for that app in your .grails directory and looking at their dependencies to find the one that is pulling the release plugin in and then either remove it or update it to a newer version as more and more plugin authors are excluding release plugin from exporting and I also believe that latest versions of release plugin don't depend on HttpBuilder anymore.
Related
I have a Spock unit test in a Grails app. In IntelliJ IDEa I can either run it with grails environment and then it means I wait a minute until the environment loads to run the test even though I do not need the environment.
The other option is to run it with JUnit. This works nicely in a Grails app without my own plugins. However, when I run it in a Grails app that has a plugin of another Grails app I have, it crashes on NoClassFound. It does not see the classes from the plugin that I included.
When I checked in IDEa the project structure, indeed the sources nowhere include a folder where the plugin classes would be included. For some reason the plugins in plugins section in BuildConfig.groovy do not appear in the classpath anywhere, they are not found in the external libraries section or anywhere else.
Is there a way to tell grails not to spin up its environment when running some of my tests? Or how can I include my plugin in the classpath for Groovyc to see it when building for testing?
The problem occurs also when simply pressing Build Project in IntelliJ IDEa. The project we are working with is simply run with grails and is never built (beyond how grails builds it). When you try to build it in IDEa, it fails on NoClassDefFound of plugin class.
Versions:
IntelliJ IDEa 2021.2
Grails 2.5.6
EDIT: Ok, it seems like grails apps are to be tested via their command-linke with grails test-app. When Grails runs in interactive mode, test-app won't have to reinitialize the environment, cause it's already running, so it runs faster.
However, as I found here Slow Grails test starting in Intellij IDEA it seems like there's no way to run grails in interactive mode from within IDEa in a way that would enable IDEa test runs to use such interactive console. Which means I'm forced to run tests via command-line. Not happy.
Edit 2: At some point in time I have managed to get the compiled tested.class to the out folder. This enabled running the test instantly via IDEa circumventing the Grails glory. However, I have no idea how I got it to out folder and after removing it I am unable to compile it again and get it there.
I'm trying to upgrade a Grails app from 3.3 to 4 (specifically 4.0.3 for now) and the Views-Json 2.0.2 plugin. Profile is angular.
When I run the app in development mode everything works. However when I attempt to build using gradlew :server-api:assemble the build fails at the Task :server-api:compileGsonViews (yeah, renamed 'server' to 'server-api' for clarity).
It looks like it's not finding my Java classes (there are a few under src/main/java).
I've see refs to setting the classpath for the compileGsonViews, but I was undable to make it work.
Anyone with suggestions?
Running on Windows 10 with latest OpenJDK 1.8.x
Somehow I seem to have stumbled on the solution. In my build.gradle I had enabled the grails pathingJar, commenting that out allowed my war to build. However with the property commented out, I was unable to use the gradlew bootRun command as it failed due to the path being too long.
The solution (for me) was to add a build property, the build file then looks like:
def usePathing = Boolean.valueOf( System.getProperty('pathingJar', 'false') )
if (usePathing) {
grails {
pathingJar = true
}
}
If I was better with gradle I think I could (maybe) determine the goal that is being targeted and use that, but the above works. The commend to assemble the war is the same; but to run the app directly I need to make it gradlew server-api:bootRun -DpathingJar=true
I'm working on a Grails plugin whose main contribution is a taglib. In Grails 3.1.11 it worked ok. I also have a simple Grails app just for testing the plugin. Enter Grails 3.2.2.
After migrating plugin and app to 3.2.2 the plugin shows no signs of life. The plugin doWithApplicationContext closure is no longer executed at app startup. The taglib is not found by gsp:s. I did the migration by creating a new plugin and app with Grails 3.2.2 and then fill in the sources.
Sorry for this vague question, but what strings should I pull to find out what's wrong?
Edit 1: Yes, I did the sanity check to have the app depend on a non-existing version of the plugin and got the expected conflict. So it's not that the plugin is totally decoupled from the app.
Edit 2: After setting DEBUG logging on packages grails.plugins and org.grails.plugins a warning message appeared. It came from org.grails.plugins.CorePluginFinder. It couldn't find the plugin descriptor (...Plugin.groovy). I examined the plugin jar, found the plugin descriptor class in a file hierarchy rooted in BOOT-INF. Clearly the plugin loader didn't look into that hierarchy. I thought I was seeing a Grails bug because I didn't know about Boot repackaging. I added a post here to that effect, but after getting Graeme's answer I deleted the post because it detracted attention.
What you are seeing is that if you run gradle assemble on a plugin then the bootRepackage task is run which re-packages the plugin JAR as a runnable JAR which is not what you want when you plan to use the plugin from an application.
If you simply run gradle publish or gradle publishToMavenLocal or gradle jar then you get the JAR file that has not been re-packaged by Boot. As far as I am aware this is not a change from Grails 3.1.
You can also disable Boot repackaging all together in the plugin build.gradle if you never plan to use the plugin as an actual application or runnable JAR file:
bootRepackage.enabled = false
I'm developing my first project in Grails framework. I'm using Spring Security Core plugin. On my machine, on newest IntelliJ Idea everything works fine. I can run, test and so on with no problems.
I have a remote machine with subversion where I upload my code and Hudson with Grails Plugin. Target which I call on my hudson builds is:
"test-app --non-interactive"
When I run build, everything goes fine - plugins are downloaded and then, bam!
Resolving plugin JAR dependencies ...
:: UNRESOLVED DEPENDENCIES :: ::::::::::::::::::::::::::::::
:: org.springframework#org.springframework.test;3.0.5.RELEASE: configuration not found in org.springframework#org.springframework.test;3.0.5.RELEASE: 'master'. It was required from org.grails.internal#League;0.1 test
Here I put whole output from Hudson Console of this project build.
That looks like a dependency issue with the Mail plugin, try going back to a non-snaphot version. I think 1.0 will be out shortly but see if 0.9 works.
Grails will automatically install the plugins it needs, you don't need to do anything manual on the build server.
You have to install the plugin of the remote machine. Because the plugins are not included in the code. The plugin will be installed under your_home/.grails/grails_version/plugins (or project/your_project).
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.