Integrate / provide example of use with jacoco about gretty

[NickStephen]

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!

[akhikhl]

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?

[NickStephen]

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).

[NickStephen]

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).

[akhikhl]

Does the task producing WAR-file have the type org.gradle.api.tasks.bundling.War (or extended from it)? Or is it completely different?

[akhikhl]

Does the task producing WAR-file depend on project.tasks.war or are these two independent?

[NickStephen]

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).

[akhikhl]

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.

[NickStephen]

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).

[akhikhl]

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.

[NickStephen]

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).

[akhikhl]

It is doable, let me think for a second 😄

[akhikhl]

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.

[NickStephen]

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).

[akhikhl]

Yes, I am working in the same direction.
After I hacked into gradle sources a bit: the way JacocoPlugin uses JavaForkOptions is wrooong 😄. No, seriously, it calls the methods are are simply not part of JavaForkOptions contract. Nevertheless, I created workaround by constructing kind of mock object:

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!

[akhikhl]

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.

[NickStephen]

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).

[akhikhl]

Understood. Then I suggest the following spec:

1. 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".
2. There will be boolean flags to completely disable *.exec files generation - independently for server and client.
3. 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).

[NickStephen]

On 24/05/2014 13:01, Andrey Hihlovskiy wrote:

Understood. Then I suggest the following spec:

1. 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".
2. There will be boolean flags to completely disable *.exec files
   generation - independently for server and client.
3. 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).

[akhikhl]

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):

1. 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'
   }

2. 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
   }

3. 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!

[akhikhl]

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 😎

[NickStephen]

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).

[akhikhl]

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?

[NickStephen]

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 ]

[akhikhl]

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.

[NickStephen]

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).

[NickStephen]

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).

[akhikhl]

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.