Gradle migration: About dependency declaration

[Philippe Mouawad <p....@ubik-ingenierie.com>]

Hello,

There are few things that are not clear to me:

1/  in http module, why do we only declare httpmime as dependency and not
httpcore and httpclient ?
2/  is it a best practice to use because ? what should it contain ?
For example I see different type of policies:

because("MessageRenderer#getValueFromFile(..., caffeine.cache.Cache)")

because("StringUtils")

because("hamcrest-date.jar was historically shipped with JMeter")


When should there be a because ?


3/ Why in protocol folder do we have a set of projects vs
a build.gradle.kts in each subfolder of protocol  ?



4/ In last eclipse version, I frequently get an error when opening
build.gradle.kts

"Check script dependencies" has encountered a problem
"An internal error occurred"
It happens for example when opening file in bom
Regards
Philippe

Re: Gradle migration: About dependency declaration

[Vladimir Sitnikov <si...@gmail.com>]

>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