I can understand you not wanting to install the components necessary to build the various jdbc versions. So I would just request that you pull the latest prebuilt version from jdbc.postgresql.org when doing a new RPM.
I will try to answer some of your other questions below.
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 understand. In the future always just grab the latest prebuilt version from jdbc.postgresql.org.
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.
The topic of having jdbc on a separate release cycle has come up in the past multiple times. And in general I have been against it (and also the move of the jdbc code to a separate project).
In general jdbc needs to release as often as the server. Because jdbc
heavily depends on all the pg_* tables and they tend to change each
release, there needs to be a corresponding release of jdbc for each
server release. Now jdbc could release on a more frequent schedule than
the server, but there currently just aren't enough developers working on
it for that to be a reality, so the current server schedule works out
There are a number of reasons that IMHO moving the source out of the
core project does not make sense for jdbc:
1) Documentation infrastructure - the server has a nice setup for
producing doc. I don't have time or want to reinvent all that for the
jdbc doc if it were in a separate project.
2) Core developer access. It is a great benefit when Tom, Bruce or some
other core hacker makes some sort of global change to the backend
tables, and they can change all the source affected including the jdbc
3) Release infrastructure - RPMs and packageing work is already done (and it usually works :-)
4) Beta program - When postgres does a beta, it is great to be a part of that automatically. Instead of needing to try and get the word out and do it on a different cycle.
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.
I think I answered all of the questions put forth here. If I haven't please let me know.
PS. Thanks for all the work you do on the RPMs. You provide a valuable service to the postgres community.
PPS. Perhaps someday you will get the beter 'upgrade' you have been asking for. I think you have been asking for it for as long as I have been a part of the postgres community.
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])