quarkus.jacoco.excludes doesn't work since 3.17.0

[waldmaier]

Describe the bug

quarkus:
  jacoco:
     excludes:
       -  "**/xsdgen1/**/*"
       -  "**/xsdgen2/**/*"

does not take effect by creating jacoco report

Expected behavior

exclude subdirectories listed in yaml config

Actual behavior

generated classes excluded in yaml are in the code coverage calculation

How to Reproduce?

mvn clean test

look into jacoco report

Output of uname -a or ver

Windows 10

Output of java -version

21

Quarkus version or git rev

3.17.0

Build tool (ie. output of mvnw --version or gradlew --version)

maven 3.9.9

Additional information

No response

[geoand]

Can you please attach a sample that worked in previous versions and doesn't in 3.17?

Thanks

[waldmaier]

Hi @geoand i am preparing a pet project and i noticed, that when using application.properties then it works, but if you use applicaton.yaml the it is not working. Seems to be an issue of quarkus yaml config

[geoand]

Cool, let me know when you have something

[waldmaier]

@geoand
here are samples: working with 3.16.1 and non working with 3.17.0

tests-with-coverage-quickstart-3-16-1-working.zip
tests-with-coverage-quickstart-3-17-0-non-working.zip

i found out, that if you exchange in application-test.yaml in 3.17.0

quarkus:
  jacoco:
    excludes:
      - "**/xsdgen1/**/*"
      - "**/xsdgen2/**/*"

to

quarkus:
  jacoco:
    excludes: "**/xsdgen1/**/*,**/xsdgen2/**/*"

than it works again

Seems, that yaml extension in 3.17.0 handles yaml arrays on different way than 3.16.1

[geoand]

Interesting, thanks.

@radcortez does that ring a bell?

[radcortez]

Yes, caused by this: smallrye/smallrye-config#1203, which we did to reduce some allocs.

This shouldn't be required, because to populate a Collection one must use Config.getValues(name, itemType), but apparently old roots use Config.getValue(name, converter) with a clever converter layering to construct the Collection.

As a workaround, one can use the already found solution described in the issue or downgrade io.smallrye.config:smallrye-config-source-yaml to 3.9.1, which is compatible.

I'll see what I can do. Sorry for the inconvenience.

[geoand]

Thanks for the info @radcortez!

[gsmet]

@radcortez so you're saying it would be fixed if we switched to @ConfigMapping? Maybe we should just do that given that's our plan?

[radcortez]

Yes, that would fix it for this case. But there may be other root classes that have the same issue.

[gsmet]

Yes, what I'm saying is that depending on the complexity of the fix, it might be better to invest this time in migrating more config roots, given that's our ultimate goal.

[radcortez]

I was thinking of reverting the YAML source change and adding a note only to remove it once we remove all the old roots.

[radcortez]

Do we agree to proceed with the revert? I did try it, and it reverts to the previous behavior without any additional changes.

I can release a new version of SR Config today and update it to this Tuesday's release.

[geoand]

Yeah, sounds fine to me

[gsmet]

Yeah, sure, that would work for me!