Thread: Wrong version of jdbc in 7.3.3 rpms
Does anyone know why apparently the 7.3beta1 version of the jdbc drivers are what is included in the 7.3.3 rpms? --Barry -------- Original Message -------- Subject: Re: [JDBC] Official JDBC driver release ? Date: Thu, 05 Jun 2003 08:14:40 +0200 From: Thomas Kellerer <spam_eater@gmx.net> To: pgsql-jdbc@postgresql.org References: <bbk5qo$bq4$1@main.gmane.org> <3EDE3083.6070001@xythos.com> Barry Lind schrieb: >> I'm a bit puzzled about the versions of the JDBC driver floating around. >> >> I initially downloaded the release for 7.3 from jdbc.postgresql.org >> >> Now I have seen that the JDBC driver which is included e.g. in the >> RPM's for 7.3.3 is a bit older and has a different name >> (pg73b1jdbc3.jar vs. pg73jdbc3.jar) > > > 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) > > --Barry Barry, thanks for the answer. The pg73b1jdbc3.jar file is contained in all the 7.3.3 rpm available on the ftp mirrors... (ok, not necessarilly all, but I checked about 3 or 4 different mirrors) I don't know who builds the rpms on the mirror sites available from www.postgresql.org Cheers Thomas ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
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
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? No idea. Just updated the "PostgreSQL Release Process" document though in case anyone (Marc) ever decides they're going to use it: http://advocacy.postgresql.org/documents/ReleaseProcess Regards and best wishes, Justin Clift > --Barry > > -------- Original Message -------- > Subject: Re: [JDBC] Official JDBC driver release ? > Date: Thu, 05 Jun 2003 08:14:40 +0200 > From: Thomas Kellerer <spam_eater@gmx.net> > To: pgsql-jdbc@postgresql.org > References: <bbk5qo$bq4$1@main.gmane.org> <3EDE3083.6070001@xythos.com> > > Barry Lind schrieb: > >>> I'm a bit puzzled about the versions of the JDBC driver floating around. >>> >>> I initially downloaded the release for 7.3 from jdbc.postgresql.org >>> >>> Now I have seen that the JDBC driver which is included e.g. in the >>> RPM's for 7.3.3 is a bit older and has a different name >>> (pg73b1jdbc3.jar vs. pg73jdbc3.jar) >> >> >> >> 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) >> >> --Barry > > Barry, > > thanks for the answer. > > The pg73b1jdbc3.jar file is contained in all the 7.3.3 rpm available on > the ftp mirrors... (ok, not necessarilly all, but I checked about 3 or 4 > different mirrors) > > I don't know who builds the rpms on the mirror sites available from > www.postgresql.org > > Cheers > Thomas > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Lamar, 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. I understand. > > 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 just right. 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 source. 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. thanks, --Barry 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.
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
Barry Lind <blind@xythos.com> writes:
> There are a number of reasons that IMHO moving the source out of the
> core project does not make sense for jdbc:
If I'm not misunderstanding here, the problem is that the JDBC sources
in the REL7_3 branch are current (if not, I'd say this is not Lamar's
fault ;-)) but that the derived .jar file was not current in the RPMs
that Lamar built?
I would suggest that we should find a mechanical solution for this.
The other derived files in the distro (bison and flex output, .html doc
files, etc) are more or less mechanically created and included --- no
one expects people to go off to a different web site to find 'em. Seems
like the JDBC jar file could be produced from the sources on the same
kind of terms.
I know Marc is a bit overworked at the moment :-( but when the dust
settles, perhaps you could consult with him about setting up an
automatic build process at developer.postgresql.org.
regards, tom lane