Re: SCRAM client vs pgjdbc packaging

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 will update the PR with the changes to Maven.

Álvaro

On 13/07/17 21:58, Dave Cramer wrote:
> # 2 is my vote!
>
> Dave Cramer
>
> davec(at)postgresintl(dot)com <mailto:davec(at)postgresintl(dot)com>
> www.postgresintl.com <http://www.postgresintl.com>
>
> On 13 July 2017 at 18:06, Jorge Solórzano <jorsol(at)gmail(dot)com
> <mailto:jorsol(at)gmail(dot)com>> wrote:
>
> 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 <mailto:sitnikov(dot)vladimir(at)gmail(dot)com>>
> wrote:
>
> Hello,
>
> Álvaro has implemented SCRAM support for pgjdbc (see
> https://github.com/pgjdbc/pgjdbc/pull/842
> <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
> <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
>
>
>

--

Álvaro Hernández Tortosa

-----------
<8K>data