From: | Álvaro Hernández Tortosa <aht(at)8Kdata(dot)com> |
---|---|
To: | Steven Schlansker <stevenschlansker(at)gmail(dot)com> |
Cc: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Markus KARG <markus(at)headcrashing(dot)eu>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: SQLJSON |
Date: | 2015-06-30 17:48:17 |
Message-ID: | 5592D661.2050305@8Kdata.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 30/06/15 19:33, Steven Schlansker wrote:
> On Jun 30, 2015, at 10:25 AM, Álvaro Hernández Tortosa <aht(at)8Kdata(dot)com> wrote:
>
>> Thanks for asking for the double-check. No, indeed I'm still asking to provide the class files for the API in the package. I feel that's the right way, and I don't see it would create conflicts unless JSR353 would create a new version, something which I believe extremely unlikely until it merges with Java10 or JDBC5 comes out, point at which we would need to change things anyway.
> I do not believe this is as unlikely as you think. For example, the javax.ws.rs JAX-RS spec has 22 different versions available on Maven Central. Granted, many of these are milestone builds and not releases, but there are already two major versions, a patch available and a new minor version coming through the pipes.
>
> So assuming these spec jars will not change is provably false. One of my fears is that if PG bundles JSR353 1.0, and I need JSR353 1.0.1, I now need to fight the driver packaging to upgrade a theoretically unrelated package.
So this is a matter of beliefs and probabilities :)
I believe it will not be changed before JDBC5/Java10. And by then,
we would need to change everything anyway. I may be wrong, of course.
So let's do a cost analysis: if I were right, we would have done
the best thing and we would have provided the most user friendly
solution. If I am not, when that happens (and we will have enough time,
since JSR is an open process), we will need to provide a new driver
version, perform the split into two packages and write all the READMEs
to explain users where/how to get the dependencies.
If, instead, we opt now for betting on JSR353 evolution, we would
need to create a new driver version, perform the split into packages and
write the READMEs.
In other words: if my bet is correct, we save some work and make
life easier for the users. If I am wrong, we will end up doing the same
work --although later on.
So unless I am missing something, cost analysis IMHO suggests to
bet on not having to do the change ;)
Regards,
Álvaro
--
Álvaro Hernández Tortosa
-----------
8Kdata
>
>> However, I don't want to insist more or suck more dev bandwitch, that's my opinion and it's been stated more times than I wish, so I would now leave the decision to the rest of you :)
>>
>> Regards,
>>
>> Alvaro
>>
>>
>> --
>> Álvaro Hernández Tortosa
>>
>>
>> -----------
>> 8Kdata
>>
>>
>>
>> On 30/06/15 18:49, Vladimir Sitnikov wrote:
>>> ah. I meant to double-check with Álvaro if he is suggesting compile
>>> type dependency.
>>>
>>> If he means that we in fact are discussing the same thing, so no
>>> contradiction exists.
>>>
>>>> However, regarding POLA you say "compile dependency" which means you
>>>> suggest _not_ including javax.json into pgjdbc.jar
>>>>
>>>> Álvaro , Can you please tell us if "using compile type dependency for both
>>>> javax.json and RI" suits you?
>>>>
>>> Vladimir
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
From | Date | Subject | |
---|---|---|---|
Next Message | Markus KARG | 2015-06-30 17:56:52 | Re: Adding new dependencies for in-core |
Previous Message | Steven Schlansker | 2015-06-30 17:33:15 | Re: SQLJSON |