You can specify <optional>true</optional> on maven dependencies. This pulls them (and transitive dependencies) for compilation but does not pull them into build artifacts. It makes life a lot easier for developers when you introduce dependencies that are only needed for specific functionality.
On Sat, Jul 15, 2017 at 7:46 AM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:
I completely agree.
Maven/XXX users will just pull the dependency and their transitive dependencies. Shading is only necessary for users who directly download and use the jar. And for these cases, the easier for the user, the better.
I expect SCRAM to become the main way to authenticate, so it would be nice if pgjdbc could just work with no need to add different jars to the classpath.
The question is how should we deal with the dependency.
1) We could make it optional & dynamic. That is we refrain from including the client to pgjdbc artifacts. In case backend is configured for SASL, pgjdbc would bail out with "please add scram-client-whatever.jar to the classpath" error.
The drawback is pgjdbc would require a certain versions of scram-client, so it might cause troubles in future if application code and pgjdbc would require different incompatible versions of the client.
2) We could incorporate scram-client to the pgjdbc artifacts, so it would just work if backend requests SASL. This option enables us to repackage the client with our own name (e.g. org.postgresql.ongress.scram...), so it will enable applications to use scram-clients of their choice.
I'm inclined to #2 (incorporate scram-client at build time), however I am not sure if it will ripple via some packaging issues.
Note: I expect we might want to add new dependencies later (e.g. for "SASL string preparation", or Netty for networking layer), so it would be nice to know limits/edge packaging cases.