https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
exception.txt
d
the project is a monorepo composed of several independent projects
it is built using kotlin dsl and the source code for each project is kotlin
the gradle build creates a “fat” jar for several projects and this apparently makes the report generation 
testCodeCoverageReport
task fail with the exception in the file
I can’t seem to find a way to fix this issue without making the JAR files “slim”, but if I do that, the JAR files won’t find the classes of the other dependencies that come from other subprojects of the monorepo
so basically the “fat” JAR allows for having projects within the monorepo with dependencies on other subprojects of the same monorepo
a
Can you show the list of tasks that are being executed when you run this task? I haven't used jacoco too extensively but from a quick glance it should run on class files not jars. If you running the jacoco and tests against a fat jar, it will include the test coverage of your dependencies, which I don't think you really want.
The jacoco task also supports includes and excludes so you can try to exclude packages you dont want (kotlin.reflect.*) and include only things which match your package structure. https://docs.gradle.org/current/userguide/jacoco_plugin.html
d
I did a 
gradle clean test
the task execution order is this: 1. 
clean
2. 
test
3. 
testCodeCoverageReport
for each subproject
I believe it is running the report against the jar files
I have tried to make it run the report against the classes instead but without success
a
The test tasks must call things like compileClasses, etc. Can you send the full list? I'm curious if jar will be in the list of tasks excited.
Executed*
d
this are all tasks being executed: 1. 
clean
2. 
compileKotlin
3. 
test
4. 
jar
5. 
testCodeCoverageReport
=> fails 6. 
testCheck
=> custom task fails too because of no. 5 failing This is the rest of the output that goes before the exception is thrown:
gradle_build.txt
not sure if this helps, but I customized the jar task for that subproject to modify the manifest main class and other properties
it was the only way I got it to produce a JAR that would run a main Kotlin function
a
I don't think the jar task should be in that task graph. Do you have anything custom in a build script to add that as a dependsOn, finalizedBy relationship or maybe linked via Inputs/Outputs? Modifying the jar task like you have done sounds absolutely fine, but I don't think jar needs to be executed as part of this workload.
d
it is not defined as a finalizedBy or dependsOn task to any other tasks
could it be the jacoco 
testCodeCoverageReport
task that dependsOn the 
jar
to create the test coverage reports?
it has been hard for me to find any examples of the plugin for kotlin dsl to specify use of classes instead of jars
a
Are you able to toss a sample project up on GitHub with your exact builds scripts and some dummy project code? I'll gladly check it out and see what I can come up with.
d
that would be awesome thanks 👍 I’ll try to get one pushed
@Andrew Lethbridge I have just finished setting up an example repo https://github.com/aros88/gradle-multiproject
you should be able to reproduce the error by doing 
./gradlew test --stacktrace
Really appreciate any help you can give 👍 thanks beforehand
a
@Daniel Rosato quick question. Do you need a runnable jar, or would something built from the application plugin work as well? What is going to be running this code?
d
hey, I need a runable jar, it will run inside a docker container
a
The application plugin can build you a zip or a tar file, which also comes with preconfigured shell scripts to handle running the application for you. Would you be open to running your code via the shell script instead of a "java jar" CLI command?
d
yeah, as long as it gets the same results, i.e. runs the main function, I would be okay with that
👍 1
a
Stay tuned.
Hope you don't mind but I've taken quite the liberty in cleaning up and refactoring the build scripts. I'm about to open up a pull request. Jacoco works fine for me now and the application works too.
d
awesome, I don’t mind at all! that is great news
a
I made a bunch of comments on the PR
The main thing is removing the fat jar stuff and replacing with application plugin. The convention plugin stuff just cleans things up but is not necessary by any means.
d
hi @Andrew Lethbridge I was checking out the PR, thank you so much for the refactor, I have learned a lot about gradle just by reading it
the 
testCodeCoverageReport
is not failing anymore which is great
but there seems to be an issue with the aggregation process of the jacoco report, it only includes the classes of the last project to be built and tested
in the sample project case, it was not showing because 
project-b
had as dependencies all others in the repo, but if you remove for example 
lib-a
from its dependencies, it stops showing in the aggregated 
index.html
as can be seen in the picture
I am not sure if its possible to have all subprojects show in the report regardless of whether they are dependencies being used or not. I thought that is what the 
jacoco-report-aggregation
plugin was supposed to do
Open in Slack
PreviousNext
Powered by