reactor / BlockHound

Java agent to detect blocking calls from non-blocking threads.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Suggestion: publish dependencies in pom.xml

suztomo opened this issue · comments

Our static analysis tool (Linkage Checker) detected Maven artifact io.projectreactor.tools:blockhound:1.0.1.RELEASE has missing dependencies (GoogleCloudPlatform/cloud-opensource-java#1286) in its pom.xml.

https://search.maven.org/artifact/io.projectreactor.tools/blockhound/1.0.1.RELEASE/jar

Screen Shot 2020-03-13 at 13 13 13

Would you declare blockhound's dependencies in pom.xml?

Hi @suztomo,

Thanks for reporting! Interesting tool!

We have these defined as compileOnly since we integrate with them only when classes are available on classpath:

compileOnly 'io.reactivex.rxjava2:rxjava:2.2.18'

The dependencies section is empty because we shade the rest of dependencies that are needed for BlockHound to operate.

It looks like the analysis tool gives a false positive result here (given that it works correctly at runtime), unless I miss something.

Thank you for explanation.

when classes are available on classpath

From BlockHound’s pom.xml in Maven Central, it’s unclear which Maven artifact your users should pick if they want to supply the classes. I suggest declaring it as “optional”. What do you think?

@suztomo the thing is - we integrate with user's "environment", the user does not need to know which classes should be there, it is rather "if they are available, we do our thing".

Adding it as optional dependencies would be slightly misleading because we don't need them, and our behaviour won't change if user adds any of them.

@bsideup Thank you for explanation. My suggestion does not apply to such case of "if they are available, we do our thing".

@suztomo thanks for sharing the problem!
Let us know if we can do anything reasonable on our side to make it easier for your tool to analyze, we would be happy to help!