Re: SQLJSON
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: SQLJSON |
Дата | |
Msg-id | 5592D661.2050305@8Kdata.com обсуждение исходный текст |
Ответ на | Re: SQLJSON (Steven Schlansker <stevenschlansker@gmail.com>) |
Список | 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 по дате отправления: