Re: Wrong version of jdbc in 7.3.3 rpms

Lamar,

I would prefer that it stay in the main source tree, (however there is
no compelling reason for this) and that we have a seperate rpm that we
can make, however Barry may have a different opinion.

My reasoning for keeping it in the main source tree is that it makes it
easier for people to download everything and have it run right out of
the box so to speak. Having people going to another site to get the rpm,
or jar is a bit of a hassle.

FYI, all we really are doing it putting the jar inside the rpm, and
having rpm install it. There's really nothing else to it.

Aside from knowing the version number we don't even use the headers.


Dave
On Fri, 2003-06-06 at 11:33, Lamar Owen wrote:
> 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.
-- 
Dave Cramer <Dave@micro-automation.net>
-- 
Dave Cramer <dave@fastcrypt.com>
fastcrypt