Re: SCRAM client vs pgjdbc packaging

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(at)8kdata(dot)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 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
> www.postgresintl.com
>
> On 13 July 2017 at 18:06, Jorge Solórzano <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> 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
>>>
>>
>>
>
> --
>
> Álvaro Hernández Tortosa
>
>
> -----------
> <8K>data
>
>