I recently upgraded Grails to V2.3.7 and noticed that when I ran grails test-app functional: the application would be started up automatically like so:
:grails-test-app-functional
| Loading Grails 2.3.7
| Configuring classpath
| Running pre-compiled script
| Running pre-compiled script.
| Environment set to test
| Environment set to test.
| Environment set to test..
| Environment set to test...
| Environment set to test....
| Environment set to test.....
| Compiling 1 source files
| Compiling 1 source files.
| Compiling 1 source files..
| Compiling 1 source files...
| Compiling 1 source files....
| Compiling 1 source files.....
| Running Grails application
Configuring Spring Security Core ...
... finished configuring Spring Security Core
| Server running. Browse to http://localhost:8080/myApplication
This did not happen in V2.3.6. My questions are:
1) Is this new in V2.3.7 or did I configure something unknowingly?
2) How do I disable this auto running of the app?
Thanks.
The app has to be started in order to run your functional tests. The functional tests interact with the running app. This has always been the case.
Related
My project has two modules, lib and lib-api, with the following responsibilities
lib-api - a pure java module that only contains interface files
lib - an android library
and I'd like to jenkins publish both modules (as jars) to an internal artifactory server for other projects to be able consume.
Using the Jenkins Artifactory Plugin, I was able to publish jars for both modules to artifactory, but my other project that depends on lib fails to build with the following gradle error
Could not find com.mygroup:lib-api:1.0.0-SNAPSHOT
My setup
Build scripts
lib-api/build.gradle
apply plugin: 'java'
apply plugin: 'maven-publish'
group = 'com.mygroup'
version = project.version
publishing {
publications {
api(MavenPublication) {
from components.java
}
}
}
lib/build.gradle
apply plugin: 'com.android.library'
apply plugin: 'com.github.dcendents.android-maven'
android { ... }
dependencies {
compile project(':lib-api')
}
group = 'com.mygroup'
version = project.version
Jenkins Artifactory plugin config
Gradle-Artifactory Integration
Publish artifacts to Artifactory
Publish Maven descriptors
Use Maven compatible patterns
Invoke Gradle script
Use Gradle Wrapper
Tasks: clean assemble -x preDexDebug -x preDexDAT -x preDexRelease
Result in Artifactory repo
+-- libs-snapshot-local
| +-- com
| | +-- mygroup
| | | +-- lib
| | | | +-- 1.0.0-SNAPSHOT
| | | | | `-- lib-1.0.0-20150508-1.jar
| | | | | `-- lib-1.0.0-20150508-1.pom
| | | | | `-- maven-metadata.xml
| | | | `-- maven-metadata.xml
| | | +-- lib-api
| | | | +-- 1.0.0-SNAPSHOT
| | | | | `-- lib-1.0.0-20150508-1.jar
Question
My understanding is that artifactory/gradle should be smart enough to resolve -SNAPSHOT into the latest timestamped snapshot and that seems to be borne out by the fact that it manages to resolve lib whether I specify latest.integration or 1.0.0-SNAPSHOT
How can I get gradle to resolve this transitive snapshot dependency from artifactory? Or get the artifactory plugin to publish the jar in such a way that gradle can resolve it?
Working theory
I noticed that the lib-api folder doesn't have a maven-metadata.xml file and the snapshot version folder doesn't have one either... or pom file. I suspect this might be the issue.
Artifactory's Jenkins plugin uses the gradle artifactory plugin under the hood for jobs that have Gradle-Artifactory integration enabled. According to the gradle artifactory plugin docs the plugin ID changes depending on whether you are using the new (maven-publish) or old (maven) publishing mechanism.
Could this be the issue? Is the Artifactory plugin applying the wrong plugin ID, perhaps because it is making it's decision based on the android library module?
tl;dr Switching to the old maven plugin for gradle fixed it.
My lib-api/build.gradle now looks like this
apply plugin: 'java'
apply plugin: 'maven'
group = 'com.mygroup'
version = project.version
ext.artifactId = project.name.toLowerCase()
project.archivesBaseName = project.artifactId
uploadArchives {
repositories {
mavenDeployer {
pom.artifactId = project.artifactId
}
}
}
Note: According to the gradle docs for the maven plugin, pom.artifactId must be explicitly defined if you've set archivesBaseName. That may have been the underlying issue with my previous configuration, but I did not go back and test it.
I am new to Grails, learning about its basics. One of the first things I did was to follow the presentation on https://grails.org/learn. According to that it should be possible to add a new method to a controller while the application is running in interactive mode (launched by the run-app target), and access that method as an action without the need to restart the application.
When I was trying to do so, I got an error message 404 from the web server with the explanation: "The requested resource is not available". The new method does work fine after the application is restarted.
I am using:
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.5 LTS"
$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) Client VM (build 24.65-b04, mixed mode)
$ grails -version
Grails version: 2.4.3
The steps I did:
$ grails create-app grailsapp
| Created Grails Application at /home/marci/grailsapp
$ cd grailsapp/
$ grails
| Daemon Started
grails> create-controller hello
| Compiling 10 source files
| Compiling 131 source files
| Created file grails-app/controllers/grailsapp/HelloController.groovy
| Created file grails-app/views/hello
| Created file test/unit/grailsapp/HelloControllerSpec.groovy
grails>
I implemented index() in grails-app/controllers/grailsapp/HelloController.groovy:
package grailsapp
class HelloController {
def index() {
render "index"
}
}
Saved the file, ran the app:
grails> run-app
| Running Grails application
| Server running. Browse to http://localhost:8080/grailsapp
| Application loaded in interactive mode. Type 'stop-app' to shutdown.
| Enter a script name to run. Use TAB for completion:
grails>
Checked http://localhost:8080/grailsapp/hello/index with the browser, worked fine.
Now I added another method:
package grailsapp
class HelloController {
def index() {
render "index"
}
def somemethod() {
render "somemethod"
}
}
Saved the file. Grails seems to have noticed the change in the source code and recompiled the file:
| Compiling 1 source files
| Compiling 1 source files.
| Compiling 1 source files..
| Compiling 1 source files...
| Compiling 1 source files....
| Compiling 1 source files.....
grails>
Now if I try to access the new method by the URL http://localhost:8080/grailsapp/hello/somemethod from the browser then Tomcat says:
HTTP Status 404 -
type Status report
message
description The requested resource is not available.
Apache Tomcat/7.0.55
Note that the message is empty. If I try to access a method that does not exist, I do get a message, therefore a different error. For example http://localhost:8080/grailsapp/hello/doesnotexist :
HTTP Status 404 - /grailsapp/hello/doesnotexist
type Status report
message /grailsapp/hello/doesnotexist
description The requested resource is not available.
Apache Tomcat/7.0.55
If I restart the application in interactive mode and try the somemethod action again, then it works fine.
grails> stop-app
| Server Stopped
grails> run-app
| Running Grails application
| Server running. Browse to http://localhost:8080/grailsapp
| Application loaded in interactive mode. Type 'stop-app' to shutdown.
| Enter a script name to run. Use TAB for completion:
grails>
Now http://localhost:8080/grailsapp/hello/somemethod return the response I expect.
My question is, should the new action be available without restart, as it is demonstrated in the presentation? Is this a bug in the release 2.4.3 of Grails? Or should I do something more to activate this feature?
Thanks in advance,
Marton
should the new action be available without restart, as it is
demonstrated in the presentation?
Yes.
Is this a bug in the release 2.4.3 of Grails?
Yes.
Or should I do something more to activate this feature?
No, you should not have to do something more.
The reloading agent should work when you are in interactive mode but apparently isn't. If you file an issue at https://jira.grails.org/browse/GRAILS we can take a look at that.
Thanks for the feedback.
I'm getting different test results when run from eclipse (STS) and from grails.
Under grails my tests error (ie dont even run) with a ClassNotFoundException
In eclipse they run successfully.
(And run-app still works fine when run from grails FWIW.)
Tests had been working in both environments for several days.
Then I deleted a number of files I didn't need (domains. controllers and the unit tests on them)
Now I have a problem.
Versions:
ubuntu 10.04
eclipse
eclipse / SpringToolSuite 3.4.0
- groovy compiler: groovy 2.07
- grails location: /home/nick/grails-2.3.6
- JDK compliance level 1.6
- JAVA_HOME=/usr/lib/jvm/java-6-openjdk
grails 2.3.6
- GRAILS_HOME=/home/nick/grails-2.3.6
- JAVA_HOME=/usr/lib/jvm/java-6-openjdk
eclipse / SpringToolSuite 3.4.0
Everything is still fine and dandy from inside eclipse / STS
select project
run as > junit test
runs 24 tests in 3 test classes
all succeed
grails 2.3.6
But from inside grails in a terminal the tests no longer run.
grails> test-app
| Compiling 2 source files.
| Error Fatal error running tests: Could not load class in test type 'unit' (Use --stacktrace to see the full trace)
| Compiling 2 source files..
| Tests FAILED - view reports in /home/nick/grails-2.3.6-workspace/imca2/target/test-reports
Browsing the test-reports shows: No tests executed.
Adding --stacktrace makes no difference, no stacktrace is provided and it still advises me to add --stacktrace.
grails test-app --stacktrace | tee /tmp/out
gives
| Loading Grails 2.3.6
| Configuring classpath
| Configuring classpath.
| Environment set to test
| Environment set to test.
| Environment set to test..
| Environment set to test...
| Environment set to test....
| Environment set to test.....
| Running without daemon...
| Compiling 1 source files
| Compiling 1 source files.
| Error Fatal error running tests: Could not load class in test type 'unit' (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.)
java.lang.RuntimeException: Could not load class in test type 'unit'
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
Caused by: java.lang.ClassNotFoundException: com.ubergen.AdvocacyStaffSpec
... 5 more
| Error Fatal error running tests: Could not load class in test type 'unit'
| Compiling 1 source files..
| Tests FAILED - view reports in /home/nick/grails-2.3.6-workspace/imca2/target/test-reports
| Error Error running forked test-app: Could not load class in test type 'unit' (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.)
java.lang.RuntimeException: Could not load class in test type 'unit'
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1254)
Caused by: java.lang.ClassNotFoundException: com.ubergen.AdvocacyStaffSpec
... 5 more
| Error Error running forked test-app: Could not load class in test type 'unit'
| Error Forked Grails VM exited with error
I've tried grails clean and clean-all first. test-app then recompiles everything, but it makes no difference - eclipse still runs the tests successfully and grails still errors without running any of them; and it doesn't matter which order I run them in.
Nor does it make any difference which order I run tests in.
What should I do?
In case it helps anyone, I'm posting my own answer after tracking problem down.
As the stacktrace showed only one of the spock tests. Grails could run the others successfully.
On closer inspection the failing test turned out to have a mistyped class name. I hadn't looked closely enough as its name is only a convention, or so I thought.
So, assuming there is a class CorrectName that needs testing but the test is mistyped as WrongNameSpec instead of CorrectNameSpec...
Here is the mistyped test code in CorrectName.groovy:
[snip]
#TestFor(CorrectName)
class WrongNameSpec extends Specification {
[snip]
This runs in eclipse/STS and tests the CorrectName class successfully.
In grails it fails with a stacktrace that says:
| Error Fatal error running tests: Could not load class in test type 'unit'
Caused by: java.lang.ClassNotFoundException: com.ubergen.CorrectNameSpec
Grails and eclipse have different target areas to put the compiled code in. Here the class files are:
./target-eclipse/classes/com/ubergen/WrongNameSpec.class
./target/test-classes/unit/com/ubergen/WrongNameSpec.class
As the stack trace said, there is no CorrectNameSpec class.
This is the corrected code and runs ok in both:
[snip]
#TestFor(CorrectName)
class CorrectName extends Specification {
[snip]
Grails is doing something like building a list of tests from the #TestFor but assuming the test classname will follow the expected convention.
Summary:
In eclipse/sts the name of the unit test is a convention, its the #TestFor that matters. In grails the name of the unit test is not just a convention, you must name it as expected, because grails will assume there is a class file that matches that name and you will get a ClassNotFoundException.
I have a legacy grails appliction that I recentyl upgraded 1.3.7 -> 2.0.4
The same thing happens after I upgrade it to 2.1.1
When I try to run test-app from GGTS I get:
| Error Error executing script TestApp: java.lang.ClassNotFoundException: grails.plugin.spock.test.GrailsSpecTestType (Use --stacktrace to see the full trace)
There is a similiar report from April on SS site.
I also see there are a lot of questions about similiar exceptions for grails 1.3.7 -- this however is a problem affecting 2.0.4.
EDIT: OK, it actually happens in command line too, but at least I can get it to work.
Unfortunately after a restart it breaks again.
Here is what I do to fix it in console, basically I upgrade to 0.7 and the downgrade to 0.5-groovy-1.7
grails> clean
| Application cleaned.
grails> refresh-dependencies
| Dependencies refreshed.
grails> test-app
| Compiling 73 source files
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
| Compiling 119 source files
| Compiling 119 source files.
| Error Error running script test-app : java.lang.ClassNotFoundException: grails.plugin.spock.test.GrailsSpecTestType (U
se --stacktrace to see the full trace)
grails> install-plugin spock
| Resolving plugin spock. Please wait...
> You currently already have a version of the plugin installed [spock-0.5-groovy-1.7]. Do you want to update to [spock-0
.7]? [y,n] y
| Plugin installed.
grails> clean
| Application cleaned.
grails> refresh-dependencies
| Application cleaned.....
> You currently already have a version of the plugin installed [spock-0.7]. Do you want to update to [spock-0.5-groovy-1
.7]? [y,n] n
| Dependencies refreshed.
grails> test-app
> You currently already have a version of the plugin installed [spock-0.7]. Do you want to update to [spock-0.5-groovy-1
.7]? [y,n] n
| Compiling 73 source files
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
| Compiling 119 source files
| Compiling 119 source files.
| Error Error running script test-app : java.lang.ClassNotFoundException: grails.plugin.spock.test.GrailsSpecTestType (U
se --stacktrace to see the full trace)
grails> install-plugin spock
| Plugin 'spock' with version '0.7' is already installed
| Plugin not installed.
grails> uninstall-plugin spock
| Uninstalled plugin [spock]
grails> clean
| Application cleaned.
grails> refresh-dependencies
| Dependencies refreshed.
grails> test-app
| Compiling 73 source files
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
| Compiling 119 source files
| Running 8 unit tests... 5 of 8
So this is apparently caused by some misbehaving plugin exporting it's spock dependency.
Sample workaround if your troublemaker is GWT:
compile(':gwt:0.8') {
exclude 'spock'
}
Thanks to Nathan Dunn
Here's the build console trace when I launch a grails 2.0 app in intellij in debug mode. It didn't used to be so verbose in grails 1.3.4
"C:\Program Files\Java\jdk1.6.0_22\bin\java" -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:57461,suspend=y,server=n -Dgrails.home=C:\grails-2.0.0.M2 -Dbase.dir=C:\apps\myapp "-Dtools.jar=C:\Program Files\Java\jdk1.6.0_22\lib\tools.jar" -Dgroovy.starter.conf=C:\grails-2.0.0.M2/conf/groovy-starter.conf -Xmx1G -Xms356m -XX:MaxPermSize=356m -javaagent:C:\Users\aressler\.IntelliJIdea10\system\groovyHotSwap\gragent.jar -Dfile.encoding=windows-1252 -classpath "C:\grails-2.0.0.M2\lib\org.codehaus.groovy\groovy-all\jars\groovy-all-1.8.2.jar;C:\grails-2.0.0.M2\dist\grails-bootstrap-2.0.0.M2.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 10.5.2\lib\idea_rt.jar" org.codehaus.groovy.grails.cli.support.GrailsStarter --main org.codehaus.groovy.grails.cli.GrailsScriptRunner --conf C:\grails-2.0.0.M2/conf/groovy-starter.conf "-Dserver.port=80 run-app"
Connected to the target VM, address: '127.0.0.1:57461', transport: 'socket'
| Loading Grails 2.0.0.M2
| Configuring classpath
| Configuring classpath.
| Environment set to development
| Environment set to development.
| Environment set to development..
| Environment set to development...
| Environment set to development....
| Environment set to development.....
| Packaging Grails application
| Packaging Grails application.
| Packaging Grails application..
| Compiling 3 source files
| Compiling 3 source files.
| Compiling 3 source files..
| Compiling 1 source files
| Compiling 1 source files.
| Compiling 1 source files..
| Compiling 1 source files...
| Compiling 1 source files....
| Compiling 1 source files.....
| Running Grails application
This is on a build where I had made no changes from the last restart. Am I wasting lots of time on each restart with it doing wasted extra packaging and compiling?
Grails 2 is not doing any more work. The reason for the repeated lines is that the new Grails 2 console is telling you that it is still working and progress is being made by adding a new period at the end of the current message.
When working in IntelliJ with Grails 2 I use --verbose and --plain-output to get legacy style logging. The Grails 2 console uses JLine for a more rich command line experience but the IntelliJ console isn't exactly comparable. I throw on --stacktrace for good measure as well when using IntelliJ.
I've created request in IntelliJ tracker to make -plain-output option by default.