You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When using Maven in Azure (e.g. via github actions), one must configure the TTL of the pooled http connections, otherwise downloading of dependencies might fail (see actions/runner-images#1499).
This can be done by running Maven with these additional options: -Dmaven.wagon.httpconnectionManager.ttlSeconds=180. Alternatively pooling can be disabled completely via -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false.
This works until the module is built, that contains dokka-maven-plugin. Then this setting is ignored. It seems, that dokka-maven-plugin downloads additional dependencies in a different way (see #1408 and #1625).
Expected behaviour
The http connection settings should be applied for dokka-maven-plugin as well. Ideally, dokka-maven-plugin does not need to do anything, it should just inherit/use the Maven settings.
To Reproduce
To make the problem evident, enable logging for http client. Start Maven with these properties:
Also use a fresh local maven repository, so that the dependencies are downloaded again - otherwise you might not see http client loggings at all.
You should see the normal Maven logs like Downloading .... and Downloaded ... and in between DEBUG logs like [DEBUG] http-outgoing-8 >> GET /maven2/.... and so on. These logs disappear as soon as dokka-maven-plugin is initialized. The dependencies for the following maven modules are downloaded without the logs of the http client.
It seems, that dokka-maven-plugin brings in an own version of the http client and replaces this within the current Maven session?
Note: the maven http client is shaded, hence the different packages: org.apache.maven.wagon.providers.http.httpclient vs. org.apache.http.impl.client. The log is enabled only on the shaded packages, that support the http configuration from Maven.
Additional context
The problem seems to stem from the way how the additional plugins are downloaded, see #1408. While the preloading or loading standard plugins as default is nice, this is maybe a complexity, that is not needed?
One alternative is, to declare these additional plugin dependencies as "normal" plugin dependencies. Then these additional plugins are on the classpath and you can detect them, e.g. via [ServiceLoader](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html. If these dependencies are declared as normal dependencies, then the normal Maven mechanics to download dependencies are inherited/used.
The text was updated successfully, but these errors were encountered:
Describe the bug
When using Maven in Azure (e.g. via github actions), one must configure the TTL of the pooled http connections, otherwise downloading of dependencies might fail (see actions/runner-images#1499).
This can be done by running Maven with these additional options:
-Dmaven.wagon.httpconnectionManager.ttlSeconds=180
. Alternatively pooling can be disabled completely via-Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false
.This works until the module is built, that contains dokka-maven-plugin. Then this setting is ignored. It seems, that dokka-maven-plugin downloads additional dependencies in a different way (see #1408 and #1625).
Expected behaviour
The http connection settings should be applied for dokka-maven-plugin as well. Ideally, dokka-maven-plugin does not need to do anything, it should just inherit/use the Maven settings.
To Reproduce
To make the problem evident, enable logging for http client. Start Maven with these properties:
Also use a fresh local maven repository, so that the dependencies are downloaded again - otherwise you might not see http client loggings at all.
You should see the normal Maven logs like
Downloading ....
andDownloaded ...
and in between DEBUG logs like[DEBUG] http-outgoing-8 >> GET /maven2/....
and so on. These logs disappear as soon as dokka-maven-plugin is initialized. The dependencies for the following maven modules are downloaded without the logs of the http client.It seems, that dokka-maven-plugin brings in an own version of the http client and replaces this within the current Maven session?
Note: the maven http client is shaded, hence the different packages:
org.apache.maven.wagon.providers.http.httpclient
vs.org.apache.http.impl.client
. The log is enabled only on the shaded packages, that support the http configuration from Maven.Dokka configuration
Installation
Additional context
The problem seems to stem from the way how the additional plugins are downloaded, see #1408. While the preloading or loading standard plugins as default is nice, this is maybe a complexity, that is not needed?
One alternative is, to declare these additional plugin dependencies as "normal" plugin dependencies. Then these additional plugins are on the classpath and you can detect them, e.g. via [ServiceLoader](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html. If these dependencies are declared as normal dependencies, then the normal Maven mechanics to download dependencies are inherited/used.
The text was updated successfully, but these errors were encountered: