Fixes#274
In #249 parallel download switched to using its own thread pool.
It could potentially lead to unbounded download if nobody throttled.
This works around the issue by fixing the number of thread to 6, which is a common per-host max connection count.
Fix https://github.com/sbt/sbt/issues/3585.
Gigahorse.config tries to load specified config file in sbt's classpath
and of course fail to find the specified config file, and throw
java.io.IOException if we specify config.resource, because
We can avoid trying to load specified config file inside sbt by
avoid using Gigahorse.config that call `ConfigFactory.load()` inside.
This commit fixes librarymanagement not to use Gigahorse.config and make
it use gigahorse.Config() which returns gigahorse's default config
without calling `ConfigFactory.load()` instead.
If the content type is null, the call for .toString on it will cause an NPE. This fixes this issue by wrapping the call in an Option, then mapping toString or falling back to null. getCharSetFromContentType handles null by returning ISO-8859-1
There are just too many instances in which sbt's code relies on
the `lastModified`/`setLastModified` semantics, so instead of moving
to `get`/`setModifiedTime`, we use new IO calls that offer the new
timestamp precision, but retain the old semantics.
Other plugins (for example: https://github.com/frugalmechanic/fm-sbt-s3-resolver)
also make use of the URLHandlerRegistry.setDefault mechanism to register handlers
for other protocols (e.g. "s3"). This change makes it so that SBT will only
register the http/https protocols and will preserve any other protocol handlers
that have already been registered.
JDK 9 complains when java.lang.reflect.Field#setAccessible is called.
So on JDK 9 to get the default Authenticator on JDK you can just call
Authenticator.getDefault(). However lm targets JDK 8..
So on JDK 8 we do what we've always done, and on JDK 9 we use java
reflection to call Authenticator.getDefault(), which is public and
doesn't require setAccessible(true).
Fixes#169
- Replace usage of OkUrlFactory with just direct calls to the OkHTTP
API. This allows us to ensure that connections get properly closed, and
provides finer-grained internal control of how we make http requests.
- Ensure that exceptions/error status codes don't cause leaked or
hanging connections. Previously, a 404 on an artifact download would
cause the underlying OkHTTP client to keep the request and connection
open. This has the effect of wasting resources, but also slowing down
overall download/resolution time to non-pipelined HTTP servers.
0lejk4
Eugene Yokota
Philippus Baalman
OlegYch
Alex Khvatov
Peter Neyens
Dale Wijnand
tanishiking24
Håkon Wold
xuwei-k
IanGabes
Dale Wijnand
Dennis Hoersch
Ståle Undheim
Stephen Nancekivell
Antonio Cunei
Tim Underwood
Leonard Ehrenfried
David Pratt
Peter Vlugter