Re: SQLJSON - Mailing list pgsql-jdbc

From Álvaro Hernández Tortosa
Subject Re: SQLJSON
Date
Msg-id 5592D661.2050305@8Kdata.com
Whole thread Raw
In response to Re: SQLJSON  (Steven Schlansker <stevenschlansker@gmail.com>)
List pgsql-jdbc
On 30/06/15 19:33, Steven Schlansker wrote:
> On Jun 30, 2015, at 10:25 AM, Álvaro Hernández Tortosa <aht@8Kdata.com> wrote:
>
>>     Thanks for asking for the double-check. No, indeed I'm still asking to provide the class files for the API in
thepackage. 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
wouldneed 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
versionsavailable on Maven Central.  Granted, many of these are milestone builds and not releases, but there are
alreadytwo 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
Ineed 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
timesthan 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@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc



pgsql-jdbc by date:

Previous
From: Steven Schlansker
Date:
Subject: Re: SQLJSON
Next
From: "Markus KARG"
Date:
Subject: Re: Adding new dependencies for in-core