Thread: Wrong version of jdbc in 7.3.3 rpms

Wrong version of jdbc in 7.3.3 rpms

From
Barry Lind
Date:
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






Re: Wrong version of jdbc in 7.3.3 rpms

From
Lamar Owen
Date:
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



Re: Wrong version of jdbc in 7.3.3 rpms

From
Justin Clift
Date:
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



Re: Wrong version of jdbc in 7.3.3 rpms

From
Barry Lind
Date:
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.





Re: Wrong version of jdbc in 7.3.3 rpms

From
Dave Cramer
Date:
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



Re: Wrong version of jdbc in 7.3.3 rpms

From
Tom Lane
Date:
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