rmannibucau commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751685353
@michael-o everything can be shaded but a few can be "hard". For properties what about supporting in the resolver.properties something like "configuration.external=path-to-conf-in-maven-base" (ex: configuration.external=conf/redisson.yaml) + if not set a minimal set of properties (host, port, ...). Kind of default simple mode and advanced mode through an external file. On the shading point, I would avoid it to keep the pluggability capabilities of external libs but I would isolate it from maven classpath (requires minimum reflection if well split, just a factory which returns a maven spi). @cstamas guess for hz we can focus on v4, nobody uses the v3 so let's not make it more complicated than needed to start as you mentionned. For redisson we can have testcontainers tests (with a flag to enable them in run-its probably since it requires docker locally and we don't want to force all dev to have it even if it is common these days). Will be easier than using a ProcessBuilder for redis and stay portable (the test can assume the OS env which is good for such simple cases). I also agree we have to focus on nolock/jvmlock/locallock (file) cases but if we consider hz/redisson as experimental then we should not put them in this repo (or enable the module for releases) IMHO. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
