>2/ is it a best practice The best practice is we should declare **used** dependencies. In other words, if a "project" (e.g. "src/protocol/http") uses some dependency, then it should be listed as a dependency.
If httpcore/httpclient APIs are used in protocol/http, then we should probably add those dependencies as well. There's https://github.com/wfhartford/gradle-dependency-analyze that can analyze the compiled bytecode and identify if class files use "undeclared" dependencies. I have not tried that yet. >1/ in http module, why do we only declare httpmime as dependency and not >httpcore and httpclient ? I added dependencies "until it compiled", and I did not perform exhaustive analysis. gradle-dependency-analyze (or something alike) would likely help us with automated analysis. https://github.com/ben-manes/gradle-versions-plugin would likely help us with providing recommendation for "avaliable updates" > is it a best practice to use because ? what should it contain ? As for me, having less dependencies is better. Especially for the cases when dependency is no longer required. For instance: IOUtils.closeQuitely(...) is deprecated, and it could be easily rewritten with try-with-resources. I was adding dependencies manually, so I added some clarification why the dependency was required. I think "because" simplifies understanding the reasons the dependency is present. >3/ Why in protocol folder do we have a set of projects vs >a build.gradle.kts in each subfolder of protocol ? Initially there were not that many dependencies for each "protocol". That is why I thought it would be easier to have just a single file. At the end of the day, each file requires 17 lines license header. Then it turned out almost each "protocol" requires "commons-lang3". Frankly speaking, I've no strong opinion here. For instance, we could move "implementation("org.apache.commons:commons-lang3")" to "subprojects" section of protocols, and it would reduce the file size dramatically. However I just think current case is fine, and we might even remove commons-lang3 use from certain places. >a build.gradle.kts in each subfolder of protocol ? During early development of the build scripts I faced an issue of "long compilation", so it was important to reduce the number of kts files. https://youtrack.jetbrains.com/issue/KT-32805 Then I managed to workaround that, however I did not touch the files since. So single file for "protocols" is both "file is quite small and observable" + "it is faster to compile than 10 individual files". Vladimir
