Re: Wrong version of jdbc in 7.3.3 rpms - Mailing list pgsql-hackers

On Thursday 05 June 2003 11:39, Barry Lind wrote:
> Does anyone know why apparently the 7.3beta1 version of the jdbc drivers
> are what is included in the 7.3.3 rpms?

> > The pg73b1jdbc3.jar file is very old (it is the 7.3 beta 1 version).
> > What RPMs are you using?  You should contact whoever produced those RPMs
> > to get them built with the current version.  The 'official' version is
> > the source code that is tagged with the 7.3.3 freeze label (which is the
> > version that is currently posted on the jdbc.postgresql.org web site)

I am whoever. :-)

I have not synced up with the version on jdbc.postgresql.org (primarily 
because I didn't know about there being a newer version).

I do not have a JDK installed here, so I don't build the JDBC driver from 
source.  So, I'll blame my own bit rot.  

Since the postgresql-jdbc RPM has no dependencies and is a 
distribution-independent RPM, I'll roll a new one.  This won't require a 
rebuild on all the distributions supported, since we're talking distribution 
independent jars.

However, I wouldn't mind pulling the JDBC subpackage out of the main set 
entirely, and having a separate RPM distribution for that.  You could 
maintain that yourself easily enough.  I can even give you a starting spec 
file, and the JDBC driver could have a separate release schedule, which might 
be appropriate anyway.

Going the one obvious next step forward, is there a compelling reason to 
include the JDBC client as part of the main tarball, rather than a separate 
project (ODBC is separate, as is the C++ and Perl clients) (and the same 
thing can be said for the Python client)?  Does the JDBC client need backend 
source code, or is it happy being built with just the necessary fe protocol 
headers? (I'm thinking out loud here -- I can see a reason for the JDBC 
driver to have a separate release schedule from the main tarball, but I'm not 
saying 'JDBC is a problem child!  Let's yank it because I don't want to deal 
with it!').  

Barry, what would be your preference?  What would best serve JDBC users? 
(other than me installing all the software necessary to build the JDBC from 
source -- this requires non-vanilla software in the form of the JDK, as well 
as the build environment that the makefiles want, and with me not being a 
Java developer at this time, I wouldn't necessarily be up on what is 
considered the 'canonical' development or runtime environments.  With the 
other portions of PostgreSQL, nothing beyond the stock distribution is 
required for build.)  

I think it would best serve the users for an active JDBC developer to make 
that distribution.  Please advise how you would like to handle this.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11