Thread

1. Wrong version of jdbc in 7.3.3 rpms

   Barry Lind <blind@xythos.com> — 2003-06-05T15:39:09Z

   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
   
   
   
   
   
   

2. Re: Wrong version of jdbc in 7.3.3 rpms

   Justin Clift <justin@postgresql.org> — 2003-06-06T08:14:47Z

   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
   
   
   

3. Re: Wrong version of jdbc in 7.3.3 rpms

   Lamar Owen <lamar.owen@wgcr.org> — 2003-06-06T15:33:04Z

   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
   
   
   

4. Re: Wrong version of jdbc in 7.3.3 rpms

   Dave Cramer <dave@fastcrypt.com> — 2003-06-06T18:38:30Z

   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
   
   
   

5. Re: Wrong version of jdbc in 7.3.3 rpms

   Barry Lind <blind@xythos.com> — 2003-06-07T00:15:29Z

   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.
   
   
   
   
   

6. Re: Wrong version of jdbc in 7.3.3 rpms

   Tom Lane <tgl@sss.pgh.pa.us> — 2003-06-07T03:46:12Z

   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