Re: JDBC 4 Compliance

Well I'm curious about a few things.

1) I just tried to build it, given I have no idea how it's not surprising
it failed to build. But there are no clear instructions on how to build it.
2) it appears to pull in at least a few other jars, how big is it when it's
built? I personally use this on an embedded system where size matters
3) It's my understanding that there will be resistance by larger consumers
to using external jars even if they are built into a single jar.
4) as it appears to only target one JDBC version what is the plan to deal
with other versions without using abstract classes like the current jar,
and if so how is that any better ?
5) does it support all current versions of postgresql (ie back to 8.4) ?

Lastly, I've never heard of an open source project where a bunch of totally
new people come in and propose forking the project without any prior
commitment to the project ?

Why is there a big desire to drop the existing code base just to support a
few new very unused features (I'm presuming this because there aren't that
many requests for them) ?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Wed, Jun 26, 2013 at 6:29 PM, Marc G. Fournier <scrappy(at)hub(dot)org> wrote:

>
> On 2013-06-26, at 15:15 , Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
> wrote:
>
> On 27/06/13 09:45, Stephen Nelson wrote:
>
> In my view the driver has already been forked by Kevin Wooten so it's
> more of a case of will it be an official fork or not? I think it would be a
> good idea to harness the enthusiasm from the contributors to the newer
> driver. However I think it would be a shame and a mistake to throw away the
> work that has gone into the stable driver. If it's not feasible to merge
> the code of both drivers I do think it would be useful to share what can be
> - particularly the functional tests.
>
> If it is decided to promote both drivers as official projects I think,
> for the benefit of the users confused about the choice, that the newer
> driver be labelled as a beta until such time as everyone is convinced in
> its stability and functionality, that it is pushed as the current driver
> and then the older one can become legacy.
>
> My interest in the project has mainly been around getting the jars
> automatically uploaded to Maven. I'm interested in reviewing driver patches
> but I don't have the knowledge of the protocol at the moment to provide any
> useful feedback other than obvious things. I would like to experiment with
> an alternative build system called Gradle and get continuous integration
> and deployment sorted out so that upon check-in the driver is built on a
> variety of platforms, tested on a variety of servers and automatically
> deployed to Maven central as well as the website. My time is a bit variable
> with kids/work/life taking a big chunk of it so I would like to collaborate
> with people on the project.
>
> Cheers,
>
> Stephen
>
> How about, when Kevin's driver is ready:
>
> 1. recommending the existing driver for JDBC3 and earlier
> 2. and Kevin's driver for JDBC4 and greater?
>
>
> Why not just create a 'pre-JDBC4 branch for the current official one and
> import Kevin's as JDBC4, for going forward? What I've read seems to
> indicate a reluctance to make a whole whack of changes on the current code,
> so putting it over to a branch shouldn't cause to much angst, should it?
>
>
>