Re: SCRAM client vs pgjdbc packaging

I vote for #2, with the maven-shade-plugin it should be easy to have an
uber-jar.

Jorge Solórzano

On Thu, Jul 13, 2017 at 5:14 AM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

> Hello,
>
> Álvaro has implemented SCRAM support for pgjdbc (see https://github.com/
> pgjdbc/pgjdbc/pull/842 ), and it would be great to merge that.
>
> However, there might be a packaging issue.
>
> Technically speaking, the client is implemented in
> https://github.com/ongres/scram (BSD 2-clause "Simplified" License).
>
> 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.
>
> Vladimir
>