Comments (28)
akhikhl commented: Hi, I have no experience (yet) with jacoco, but I am curious in trying this. If I integrate jacoco support in Gretty, can you contribute with the feedback/experience using it? Greetings from Germany,
I can certainly try to do so, yes. Thx!
from gretty.
Let's start the party
For discussion:
We are talking about code coverage of integration tests, right? That means: test task starts jetty server with web-app, then concrete test class opens a browser and simulates user work (or just creates HttpBuilder and sends AJAX requests, as you please), when done - jetty server stops.
Within this scenario - what we want to instrument and cover: client-side or server-side? Or both?
What level of control you need there? Or is it okay, that "things just work" and you get jacoco test reports in designated directories?
What other scenarios/tasks you need to be instrumented with jacoco?
from gretty.
On 22/05/2014 19:35, Andrey Hihlovskiy wrote:
Let's start the party
😄
For discussion:
We are talking about code coverage of integration tests, right? That
means: test task starts jetty server with web-app, then concrete test
class opens browser and simulates user work (or just creates
HttpBuilder and simulates AJAX requests, as you like), when done -
jetty server stops.Yes
Within this scenario - what we want to instrument and cover:
client-side or server-side? Or both?Both... but today the client side already works, it's the server side
that's not getting the jacoco agent deployed into the JVM and thus isn't
generating coverage reports.What level of control you need there? Or is it okay, that "things just
work" and you get jacoco test reports in designated directories?Ideally out of the box things would 'just work'.
For these tests we are bundling some jars/classes which we do not want
to include in the coverage report, so ideally we'd be able to
include/exclude classes on a provided classpath. Since junit tests are
in the same package as their implementation classes, if the test jars
are included in our jetty deployment (which I'm doing since we provide
some mock classes in the test source tree), we need to exclude those
test classes from instrumentation - unfortunately we cannot exclude the
test classes later in the jacoco report task since that task only lets
you filter by package.
What other scenarios/tasks you need to be instrumented with jacoco?
We're already instrumenting all our test runs with jacoco but the issue
we're seeing today is specific to when we deploy an embedded jetty in
our test run using the jetty plugin, the jacoco agent is not enabled for
the jetty webserver and so the code coverage is not being recorded for
our tests which are being executed inside the same gradle build.
Thanks...
[ nick ]
—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
I've just started seeing if I can use gretty as-is as a drop-in
replacement for the jetty plugin (without trying for jacoco coverage
yet), and am missing something - I'm not sure how to specify which
warfile I want to deploy. Is this possible?
Here's the relevant part of my gradle using the jetty plugin - in
particular it's using a specific WAR file built for testing, which
includes some mock and some classes on which the webapp depends that
aren't in the production WAR.
httpPort = 6999
stopPort = 9451
stopKey = 'stop'jettyRunWar {
dependsOn(testWar)contextPath = 'datamodel' webApp = testWar.archivePath daemon = 'true'
}
task testInteg(type: Test) {
dependsOn(jettyRunWar) finalizedBy(jettyStop) // Gather test suite definition files def suiteFiles = sourceSets.testInteg.resources.matching({ include "**/testng.xml" }) // Add the test suite to testng useTestNG() { suiteFiles.each { File f -> suites f } } testClassesDir = sourceSets.testInteg.output.classesDir classpath = sourceSets.testInteg.runtimeClasspath
}
A naive mapping to gretty gives this:
jettyStartWar {
dependsOn(testWar)port 6999 statusPort 6998 servicePort 6997 contextPath = 'datamodel' webApp = testWar.archivePath
// daemon = 'true'
}jettyStop {
servicePort 6997
}... but webApp doesn't exist as a parameter to jettyStartWar.. do I need
to define a jetty.xml file? I'm only
using jetty for integration testing, not for production.
Thx,
[ nick ]
On 22/05/2014 19:35, Andrey Hihlovskiy wrote:
Let's start the party
😄
For discussion:
We are talking about code coverage of integration tests, right? That
means: test task starts jetty server with web-app, then concrete test
class opens browser and simulates user work (or just creates
HttpBuilder and simulates AJAX requests, as you like), when done -
jetty server stops.
Within this scenario - what we want to instrument and cover:
client-side or server-side? Or both?
What level of control you need there? Or is it okay, that "things just
work" and you get jacoco test reports in designated directories?
What other scenarios/tasks you need to be instrumented with jacoco?—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
Does the task producing WAR-file have the type org.gradle.api.tasks.bundling.War (or extended from it)? Or is it completely different?
from gretty.
Does the task producing WAR-file depend on project.tasks.war or are these two independent?
from gretty.
On 23/05/2014 14:00, Andrey Hihlovskiy wrote:
Does the task producing WAR-file have the type
org.gradle.api.tasks.bundling.War (or extended from it)? Or is it
completely different?It's of type 'War'... just its not the default war task, there are two
in the gradle build, the 'production' war and the test war...
[ nick ]
configurations {
testWarLib
}
dependencies {
testWarLib configurations.jerseyServer
testWarLib configurations.jerseyServlet
testWarLib configurations.commonsLang
testWarLib configurations.runtime
}
war {
dependsOn restDoc
baseName = archiveBaseName
from restDocRootDir, {
into "doc/v${project.version}"
}
}
task testWar(type: War, dependsOn: testIntegClasses) {
baseName = archiveBaseName
classifier = 'Test'
classpath configurations.testWarLib
from(sourceSets.testInteg.output.classesDir) {
into('WEB-INF/classes')
}
from (sourceSets.testInteg.output.resourcesDir) {
into('WEB-INF/classes')
}
}
—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
I understand the problem as follows: it should be possible to specify arbitrary War-task as an input and dependency to gretty-war tasks (jettyRunWar, jettyRunWarDebug, jettyStartWar, jettyStartWarDebug).
OK, I will develop solution for it.
from gretty.
On 23/05/2014 14:10, Andrey Hihlovskiy wrote:
I understand the problem as follows: it should be possible to specify
arbitrary War-task as an input and dependency to gretty-war tasks
(jettyRunWar, jettyRunWarDebug, jettyStartWar, jettyStartWarDebug).
OK, I will develop solution for it.Fantastic - that's correct - thanks.
[ nick ]
—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
Here is the solution:
task myJetty(type: JettyStartTask) {
dependsOn testWar
inplace = false
warResourceBase = testWar.archivePath.toString()
}
Explanation: we instantiate gretty task JettyStartTask and configure it, so that it depends on testWar. inplace=false
means that task should run on the WAR-file (not on projects classpath). warResourceBase
instructs JettyStartTask, where the WAR-file is located.
Please note that there is a bug (stack overflow) in Gretty, that prevents from using simpler assignment warResourceBase = testWar.archivePath
, but toString
at the end works around the bug. I'll certainly fix it in the next version.
Wiki contains more information on gretty tasks and gretty task classes.
from gretty.
That seems to be working as a base, I've added 'interactive=false' and
specified the full path to the JettyStartTask, but it's
running in the foreground instead of being a background process... but
it replies to manual HTTP GETs already.
I guess I need to leverage the integration test support somehow,
overriding the jettyBeforeIntegrationTest and jettyAfterIntegrationTest
classes to use my own customized start and stop classes ... I'm not at
all sure how to do this I'm afraid.
Thx,
[ nick ]
On 23/05/2014 14:35, Andrey Hihlovskiy wrote:
Here is the solution:
task myJetty(type: JettyStartTask) {
dependsOn testWar
inplace = false
warResourceBase = testWar.archivePath.toString()
}Explanation: we instantiate gretty task JettyStartTask and configure
it, so that it depends on testWar. |inplace=false| means that task
should run on the WAR-file (not on projects classpath).
|warResourceBase| instructs JettyStartTask, where the WAR-file is located.Please note that there is a bug (stack overflow) in Gretty, that
prevents from using simpler assignment |warResourceBase =
testWar.archivePath|, but |toString| at the end works around the bug.
I'll certainly fix it in the next version.Wiki contains more information on gretty tasks
https://github.com/akhikhl/gretty/wiki/Gretty-tasks and gretty task
classes https://github.com/akhikhl/gretty/wiki/Gretty-task-classes.—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
It is doable, let me think for a second
from gretty.
Here is the solution to the problem:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'org.akhikhl.gretty:gretty-plugin:+'
}
}
repositories {
jcenter()
}
apply plugin: 'gretty'
import org.akhikhl.gretty.*
ext {
archiveBaseName = 'someArchiveBaseName'
}
war {
baseName = archiveBaseName
}
task testWar(type: War) {
baseName = archiveBaseName
classifier = 'Test'
}
task myIntegrationTest {
doLast {
println 'Ahoy!'
}
}
task myBeforeIntegration(type: JettyBeforeIntegrationTestTask) {
dependsOn testWar
inplace = false
warResourceBase = testWar.archivePath.toString()
integrationTestTask = 'myIntegrationTest'
setupIntegrationTestTaskDependencies()
}
task myAfterIntegration(type: JettyAfterIntegrationTestTask) {
integrationTestTask = 'myIntegrationTest'
setupIntegrationTestTaskDependencies()
}
Expected output:
user@host:~/Projects/gretty_customwar$gradle myIntegrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:war
:prepareWarWebApp
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:testWar
:myBeforeIntegration
scanInterval not specified (or zero), scanning disabled
Auto-configuring server connectors
Jetty server 9.1.0.v20131115 started.
someArchiveBaseName-Test.war runs at the address http://localhost:8080/gretty_customwar
servicePort: 9900, statusPort: 9901
:myIntegrationTest
Ahoy!
:myAfterIntegration
Jetty server stopped.
BUILD SUCCESSFUL
Explanation: instead of JettyStartTask (which is modal, you are right), we create before- and after- tasks, that are non-modal and operate with each other and with integration task smoothly.
The property integrationTestTask
is important: it tells, which task is to be wrapped with before- and after-tasks. The call setupIntegrationTestTaskDependencies is important for both - it configures dependencies between three:
- integrationTask dependsOn JettyBeforeIntegrationTestTask
- integrationTask finalizedBy JettyAfterIntegrationTestTask
Note that you never call before- or after- tasks yourself. They are called automatically each time an integration test is run.
If there are more integration test tasks, each one could be wrapped with before/after.
from gretty.
Great - I've got this integrated into my build now and gretty is working
in replacement for the jetty plugin, however I don't yet see my
codecoverage for the server-side of things.
According to the jacoco plugin documentation, it can auto-cover anything
that implements the JavaForkOptions:
http://www.gradle.org/docs/current/userguide/jacoco_plugin.html
While all tasks of type |Test|
http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.testing.Test.html
are automatically enhanced to provide coverage information when the
|java| plugin has been applied, any task that implements
|JavaForkOptions|
http://www.gradle.org/docs/current/javadoc/org/gradle/process/JavaForkOptions.html
can be enhanced by the JaCoCo plugin. That is, any task that forks
Java processes can be used to generate coverage information.
It supplies an example:
apply plugin:"application"
apply plugin:"jacoco"mainClassName ="org.gradle.MyMain"
jacoco {
applyTo run
}task applicationCodeCoverageReport(type:JacocoReport){
executionData run
sourceSets sourceSets.main
}
I see reference to JavaForkOptions in the gretty sources, but nothing
indicating that it's "implementing" JavaForkOptions ... I tried naively
adding this but it didn't work:
jacoco {
applyTo myBeforeIntegration
}
This would be the last step to victory for an example that would be
including jacoco coverage...
Many thanks,
[ nick ]
On 23/05/2014 15:41, Andrey Hihlovskiy wrote:
Here is the solution to the problem:
buildscript {
repositories {
jcenter()
}dependencies {
classpath 'org.akhikhl.gretty:gretty-plugin:+'
}
}repositories {
jcenter()
}apply plugin: 'gretty'
import org.akhikhl.gretty.*
ext {
archiveBaseName = 'someArchiveBaseName'
}war {
baseName = archiveBaseName
}task testWar(type: War) {
baseName = archiveBaseName
classifier = 'Test'
}task myIntegrationTest {
doLast {
println 'Ahoy!'
}
}task myBeforeIntegration(type: JettyBeforeIntegrationTestTask) {
dependsOn testWar
inplace = false
warResourceBase = testWar.archivePath.toString()
integrationTestTask = 'myIntegrationTest'
setupIntegrationTestTaskDependencies()
}task myAfterIntegration(type: JettyAfterIntegrationTestTask) {
integrationTestTask = 'myIntegrationTest'
setupIntegrationTestTaskDependencies()
}Expected output:
|user@host:~/Projects/gretty_customwar$gradle myIntegrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:war
:prepareWarWebApp
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:testWar
:myBeforeIntegration
scanInterval not specified (or zero), scanning disabled
Auto-configuring server connectors
Jetty server 9.1.0.v20131115 started.
someArchiveBaseName-Test.war runs at the address http://localhost:8080/gretty_customwar
servicePort: 9900, statusPort: 9901
:myIntegrationTest
Ahoy!
:myAfterIntegration
Jetty server stopped.BUILD SUCCESSFUL
|Explanation: instead of JettyStartTask (which is modal, you are
right), we create before- and after- tasks, that are non-modal and
operate with each other and with integration task smoothly.
The property |integrationTestTask| is important: it tells, which task
is to be wrapped with before- and after-tasks. The call
setupIntegrationTestTaskDependencies is important for both - it
configures dependencies between three:
- integrationTask dependsOn JettyBeforeIntegrationTestTask
- integrationTask finalizedBy JettyAfterIntegrationTestTask
Note that you never call before- or after- tasks yourself. They are
called automatically each time an integration test is run.If there are more integration test tasks, each one could be
facilitated with before/after.—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
Yes, I am working in the same direction.
After I hacked into gradle sources a bit: the way JacocoPlugin uses JavaForkOptions is wrooong
class JavaForkOptionsWrapper implements JavaForkOptions, ExtensionAware {
@Delegate
private final JavaForkOptions delegate
private final dummyContainer
JavaExecSpecWrapper(Project project, JavaForkOptions delegate) {
this.delegate = delegate
dummyContainer = project.container(Runner)
}
void doFirst(Closure closure) {
closure()
}
ExtensionContainer getExtensions() {
dummyContainer.extensions
}
def getJacoco() {
dummyContainer.extensions.jacoco
}
String getName() {
'JavaExecSpecWrapper'
}
}
where delegate is real JavaForkOptions to be passed to javaexec.
When we pass such object to jacoco.applyTo, it works like magic
So, yes, solution is near!
from gretty.
Here are news: I've started implementing jacoco support on branch "jacoco_support". What already works: execution-data is generated with jettyBeforeIntegrationTest and jettyAfterIntegrationTest - both client and server, html report is generated for client. Pending: html report for server and programmatic interface to gretty-jacoco integration. Currently implemented there's only one option - as soon as jacoco plugin is applied, gretty integrates reports. Of course, we need to fine-tune this.
from gretty.
On 24/05/2014 11:42, Andrey Hihlovskiy wrote:
Here are news: I've started implementing jacoco support on branch
"jacoco_support". What already works: execution-data is generated with
jettyBeforeIntegrationTest and jettyAfterIntegrationTest - both client
and server, html report is generated for client. Pending: html report
for server and programmatic interface to gretty-jacoco integration.
Currently implemented there's only one option - as soon as jacoco
plugin is applied, gretty integrates reports. Of course, we need to
fine-tune this.Great!
I should point out that I'll be using this in a larger project with
other jacoco exec files to integrate into the same code coverage report,
so really the important output IMHO are the exec files from which we
should be able to use the standard reporting tasks...
Thx again!
[ nick ]
—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
Understood. Then I suggest the following spec:
- by default Gretty generates *.exec files only. When we apply JettyBeforeIntegrationTestTask and JettyAfterIntegrationTestTask with integrationTaskName='XYZ', then the files are named as "${project.buildDir/jacoco/XYZ.exec" and "${project.buildDir/jacoco/XYZ_server.exec".
- There will be boolean flags to completely disable *.exec files generation - independently for server and client.
- Optionally gradle tasks and extensions will support reports (html, ...), configurable in the same syntax as in JacocoReport (actually, things will be simply delegated to it, no rocket science).
from gretty.
On 24/05/2014 13:01, Andrey Hihlovskiy wrote:
Understood. Then I suggest the following spec:
- by default Gretty generates *.exec files only. When we apply
JettyBeforeIntegrationTestTask and JettyAfterIntegrationTestTask with
integrationTaskName='XYZ', then the files are named as
"${project.buildDir/jacoco/XYZ.exec" and
"${project.buildDir/jacoco/XYZ_server.exec".- There will be boolean flags to completely disable *.exec files
generation - independently for server and client.- Optionally gradle tasks and extensions will support reports (html,
...), configurable in the same syntax as in JacocoReport
http://www.gradle.org/docs/current/dsl/org.gradle.testing.jacoco.tasks.JacocoReport.html
(actually, things will be simply delegated to it, no rocket science).sounds perfect!
[ nick ]
—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
News: jacoco support feature is now ready and supplied with working examples on branch jacoco_support.
Updated spec (based on hands-on experience with jacoco and least-surprise approach):
-
All jetty start tasks (jettyRun, jettyStart, jettyBeforeIntegrationTest, ...) now support jacoco task extension and can be configured like this:
tasks.jettyBeforeIntegrationTest.jacoco { append = false destinationFile = new File(project.buildDir, 'jacoco/integrationTest_server.exec') // excludes.add 'packagename.ClassName' }
-
jacoco task extension is disabled (
enabled = false
) for all gretty start tasks except jettyBeforeIntegrationTest and farmBeforeIntegrationTest. This is the least-surpise behavior, but it can be changed by setting:tasks.jettyRun.jacoco { enabled = true }
-
After hands-on experience with jacoco it dawned on me, that default reports (point 3 of initial spec) was a bad idea. Gretty has nothing to do with jacoco reports. It's up to the user to define JacocoReport task and to link it with integration-test task.
Summary: jacoco support in Gretty consists of two parts:
- Adding jacoco task extension to all jetty start tasks, as soon as jacoco plugin is applied.
- Passing jacoco JVM arguments to jetty server.
There are two examples on jacoco_support branch - "jacocoExample" and "farmJacoco" - that show jacoco support in action.
Gretty release with jacoco support is coming soon!
from gretty.
Jacoco feature is now on master. Gretty version 0.0.22, with Jacoco support, is at jcenter.
Here are Jacoco-related documentation and examples.
Happy coding
from gretty.
Excellent - I've started integrating this but still have a last
stumbling block:
I used to have this in my before and after tasks:
setupIntegrationTestTaskDependencies()
This no longer seems to be understood in the syntax, but without this,
my before and after
methods are not being called when running my tests, so the webserver is
not running and the
tests fail...
A last note - is there an easy way of adding all the classes in a given
subdirectory (testInteg.output.classesDir) the to the excludes list?
Here are my modified gradle functions which integrate jacoco, but don't
cause the webserver to start when testInteg is invoked...
Many thanks for this excellent bit of code! :-)
[ nick ]
test {
useTestNG() {
// Gather test suite definition files
def suiteFiles = sourceSets.test.resources.matching({
include "**/testng.xml"
})
// Add the test suite to testng
useTestNG() {
suiteFiles.each { File f -> suites f }
}
}
}// start up jetty before running testInteg
task jettyBeforeIntegration(type: JettyBeforeIntegrationTestTask) {// configure gretty to use jacoco on server side jacoco { append = false destinationFile = new File(project.buildDir,
'jacoco/testInteg_server.exec')
}dependsOn testWar inplace = false warResourceBase = testWar.archivePath.toString() integrationTestTask = 'testInteg' contextPath = 'datamodel' port 6999 statusPort 6998 servicePort 6997
}
// stop jetty after running testInteg
task jettyAfterIntegration(type: JettyAfterIntegrationTestTask) {
integrationTestTask = 'testInteg'servicePort 6997
}
task testInteg(type: Test) {
// Gather test suite definition files def suiteFiles = sourceSets.testInteg.resources.matching({ include "**/testng.xml" }) // Add the test suite to testng useTestNG() { suiteFiles.each { File f -> suites f } } testClassesDir = sourceSets.testInteg.output.classesDir classpath = sourceSets.testInteg.runtimeClasspath
}
On 26/05/2014 08:21, Andrey Hihlovskiy wrote:
Jacoco feature is now on master. Gretty version 0.0.22, with Jacoco
support, is at jcenter.
Here are Jacoco-related documentation and examples
<../wiki/Code-coverage-support>.
Happy coding 😎—
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
I've made syntax change with setupIntegrationTestTaskDependencies. I must have notified you, sorry. The old syntax:
task('MyBeforeIntegrationTest', type: JettyBeforeIntegrationTest) {
integrationTestTask = 'MyIntegrationTest'
setupIntegrationTestTaskDependencies()
}
should be replaced with the new one:
task('MyBeforeIntegrationTest', type: JettyBeforeIntegrationTest) {
integrationTestTask 'MyIntegrationTest'
}
i.e. integrationTestTask is now a function, that does all needed side effects.
Same change for JettyBeforeIntegrationTest and JettyAfterIntegrationTest.
Usually I am trying to stay backward-compatible, but in this case it is a necessary change in order to reduce a potential for errors. It was far too easy to forget to call setupIntegrationTestTaskDependencies.
Subdirectory to the excludes list: hm, I am aware of wildcards support in the excludes. Maybe, something like packageName.*
will do?
from gretty.
On 26/05/2014 10:41, Andrey Hihlovskiy wrote:
I've made syntax change with setupIntegrationTestTaskDependencies. I
must have notified you, sorry. The old syntax:task('MyBeforeIntegrationTest', type: JettyBeforeIntegrationTest) {
integrationTestTask = 'MyIntegrationTest'
setupIntegrationTestTaskDependencies()
}should be replaced with the new one:
task('MyBeforeIntegrationTest', type: JettyBeforeIntegrationTest) {
integrationTestTask 'MyIntegrationTest'
}i.e. integrationTestTask is now a function, that does all needed side
effects.Usually I am trying to stay backward-compatible, but in this case it
is a necessary change in order to reduce a potential for errors. It
was far too easy to forget to call setupIntegrationTestTaskDependencies.ok - agree with you on that, but with the above change (simply removing
the line on setting up dependencies) my beforeIntegrationTest task
(called jettyBeforeIntegration) is no longer being invoked before
running my integration tests..
In fact, running gradle with --debug, the only reference to this task is
where it says it's applying jacoco to it:
10:45:49.699 [DEBUG]
[org.gradle.testing.jacoco.plugins.JacocoPluginExtension_Decorated]
Applying Jacoco to test
10:45:50.355 [DEBUG]
[org.gradle.testing.jacoco.plugins.JacocoPluginExtension_Decorated]
Applying Jacoco to jettyBeforeIntegration
10:45:50.399 [WARN]
[org.gradle.internal.featurelifecycle.LoggingDeprecatedFeatureHandler]
Deprecated dynamic property: "integrationTestTask" on "project
':target-web'", value: "testInteg".
10:45:50.770 [DEBUG]
[org.gradle.testing.jacoco.plugins.JacocoPluginExtension_Decorated]
Applying Jacoco to testInteg... I tried moving the line integrationTestTask = 'testInteg' to the
end of the task to make sure everything else was initialized first
(maybe this doesn't make sense?) but this didn't change anything.Subdirectory to the excludes list: hm, I am aware of wildcards support
in the excludes. Maybe, something like "packageName.*" will do?Unfortunately not since the unit tests are in the same package as the
functionality itself... not to worry, I'll try and find this out on my side.
Thx,
[ nick ]
from gretty.
Please mention the change: instead of integrationTask = "something"
there's now integrationTask "something"
. Equal sign ("=") should be dropped
Order of declarations within task definition does not matter.
from gretty.
d'oh - sorry, I missed the removal of the equals sign, you did say it
was now a function... sorry about that, not a practiced groovy developer :-/
Indeed it's working fine now, many thanks!
[ nick ]
On 26/05/2014 11:08, Andrey Hihlovskiy wrote:
Please mention the change: instead of |integrationTask = "something"|
there's now |integrationTask "something"|. Equal sign ("=") should be
dropped😄 —
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
Just one minor further comment - it might be worth mentioning in the
example that one can set 'debug=true' in the JettyBeforeIntegrationTest
if it's not done so already... I looked into the code to see what to set
here..
Thx again!
[ Nick ]
On 26/05/2014 11:08, Andrey Hihlovskiy wrote:
Please mention the change: instead of |integrationTask = "something"|
there's now |integrationTask "something"|. Equal sign ("=") should be
dropped😄 —
Reply to this email directly or view it on GitHub
#21 (comment).
from gretty.
It is actually documented here: https://github.com/akhikhl/gretty/wiki/Gretty-task-classes#properties-3
I will additionally document it in code-coverage examples, so that number of cross-lookups is reduced.
from gretty.
Related Issues (20)
- Hot deploy and fast reload not working
- Enable to run appStart task because of NoClassDefFoundError: Lorg/jCharts/properties/PieChart2DProperties
- Problem in appStart Task
- Examples folder is missing from master branch HOT 1
- Global logging.properties file for Tomcat
- how to appStartWar with war generated in subproject? HOT 2
- AppIntegrationTest is not using src/test/resources but src/main/resources for the server test instance
- Multiproject builds: Exception in thread "Thread-x" java.lang.IllegalStateException: The configuration ... was resolved from a thread not managed by Gradle. HOT 2
- jettyRun task produces java.lang.ClassNotFoundException: org.eclipse.jetty.security.DefaultAuthenticatorFactory
- Could not read script 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin'
- Object of class 'org.akhikhl.gretty.JettyWebAppContext' is not of type 'org.eclipse.jetty.webapp.WebAppContext'. Object Class and type Class are from different loaders
- this link is obsolete
- Can I use Gretty to generate code with OpenAPI?
- KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory HOT 2
- "Cannot run Project.afterEvaluate" crash when Gretty applied to a Gradle sub-module via plugins block HOT 1
- org.akhikhl.gretty.Runner.run issue
- For a non spring boot application, gretty is complaining for spring boot dependency HOT 1
- gretty versions after 2.0.0 no longer available in the recommended repos HOT 2
- Gretty unable to find jstl.core
- apply from: 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin' and Could not HEAD
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gretty.