Thread: Upgrade to 9 questions

Do I need the new version 9 JDBC to access the version 9 server from Java, or will the version 8 jdbc able to connect the version 9 server?

Version 9.0-801 jdbc is released, but still missing from Maven Central.
The latest what can be found there is http://repo1.maven.org/maven2/postgresql/postgresql/8.4-701.jdbc4/

Is there anybody working on this issue?

On Fri, Oct 1, 2010 at 9:14 AM, Albert Kurucz <albert.kurucz@gmail.com> wrote:

Do I need the new version 9 JDBC to access the version 9 server from Java, or will the version 8 jdbc able to connect the version 9 server?

Version 9.0-801 jdbc is released, but still missing from Maven Central.
The latest what can be found there is http://repo1.maven.org/maven2/postgresql/postgresql/8.4-701.jdbc4/

Is there anybody working on this issue?

"Bremer, Gerd" <gerd.bremer@coremedia.com> wrote:

> I do not feel comfortable to upload artefacts from a project I
> haven't contributed to.

Keeping such a repository up-to-date with current jars could be
considered a contribution.

> Having latest releases in the Maven central repo is important, so
> I was surprised when I didn't find them.

It's not important to everyone; quite likely just to a minority.
Things in an open source project often get done by those
people to whom they are important.  I suspect that if you pull
official jars from the JDBC download page, nobody will find anything
amiss if you keep Maven central current.

-Kevin

Thanks Gerd for answering my second question.
Anybody could comment on the other one, about the version compatibility?

Albert Kurucz <albert.kurucz@gmail.com> wrote:

> Anybody could comment on the other one, about the version
> compatibility?

I generally go by what the download page says:

http://jdbc.postgresql.org/download.html#current

This currently recommends 9.0-801 for PostgreSQL version 7.2 or
newer.  I seem to remember some compatibility problems with using
the older driver against 9.0, although I don't remember what the
issues were.  I would be particularly skeptical about using an older
JDBC jar against 9.0 if you care about the JDBC metadata objects.
(It's hard for an old driver to know what future releases are doing
with the system tables.)

-Kevin

On Fri, 1 Oct 2010, Kevin Grittner wrote:

>> Anybody could comment on the other one, about the version
>> compatibility?
>
> This currently recommends 9.0-801 for PostgreSQL version 7.2 or
> newer.  I seem to remember some compatibility problems with using
> the older driver against 9.0, although I don't remember what the
> issues were.  I would be particularly skeptical about using an older
> JDBC jar against 9.0 if you care about the JDBC metadata objects.
> (It's hard for an old driver to know what future releases are doing
> with the system tables.)
>

Aside from metadata changes, the key change that needs a new JDBC driver
for a 9.0 server is the format of bytea data.  You need to use the new
JDBC driver or to adjust your server settings to return bytea data in the
old format or you will silently get corrupt data.

Kris Jurka

Samuel,

I hat to disagree about that (It is really easy to build yourself.)!

Macro processing in Java sources is the worst nightmare for those who would want to take the source files and build it themselves.
See:
"
    private static Connection makeConnection(String url, Properties props) throws SQLException {
        return new @JDBCCONNECTCLASS@(host(props), port(props),
                                      user(props), database(props),
                                      props, url);
    }
"

"
public static final int MAJORVERSION = @MAJORVERSION@;
"

In "Driver.java.in" !!

On 2/10/2010 1:39 AM, Kevin Grittner wrote:
> I suspect that if you pull
> official jars from the JDBC download page, nobody will find anything
> amiss if you keep Maven central current.

Frankly, that's more than a little bit worrying. Joe Black Hat could
rather trivially insert an exciting little back door into a version they
"helpfully" push to Central. PgJDBC doesn't have published md5sums or
gpg signatures, so there's no convenient way to verify that the jar
being submitted is actually approved by the project.

I've been concerned about Maven's apparent lack of cryptographic
verification before (and in fact the apparent lack of concern across the
entire Java community), but I'd foolishly assumed Central uploads
required authorization to push to a given groupId's section.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Albert Kurucz wrote:
> Samuel,
>
> I hat to disagree about that (It is really easy to build yourself.)!
>
> Macro processing in Java sources is the worst nightmare for those who
> would want to take the source files and build it themselves.

The Ant build.xml buildfile shipped with the source does all the
necessary substitutions for you before compiling, so I'm not quite sure
what the problem is.

Of course, if you don't want to use the buildfile, you'll have to do
that work yourself, but that's a bit like trying to build gcc without
using its Makefiles - why would you want to do that?!

-O

Oliver,

What command do I need to give to Ant to make the necessary substitutions?
Why source files are not release after preprocessing?
Java source files please for the non Ant users!

Albert

Albert Kurucz wrote:
> Oliver,
>
> What command do I need to give to Ant to make the necessary substitutions?

The slightly misleadingly named target "driver" will configure the build
environment and do all the substitutions, but not actually compile the
result. So: "ant driver"

> Why source files are not release after preprocessing?

Because the substitutions that are needed are different depending on
your build environment e.g. which JDBC version and JDK you are building
for. The ant buildfile handles both detecting your build environment and
performing suitable substitutions. Releasing multiple source
distributions, each of which only works for one environment, where the
only difference is in the 3-4 templated files - that'd be confusing and
unnecessary when the build process already handles it, don't you think?

> Java source files please for the non Ant users!

I don't think we really support building the driver except via ant, it
is something of a de-facto standard for building Java these days. (Ok,
now the Maven people are going to yell at me ;-))

Consider it a prerequisite for building the driver, just like having a
functional JDK installed is a prerequisite.

-O

It's been a while since I looked. but isn't the driver target a dependency for the actual compilation target?  I seem to recall that all I did when I built it was to download it, change directory into the distribution, and type 'ant'.  It's pretty hard to ask for a simpler build process than that, I think.

Samuel Gendler wrote:
> It's been a while since I looked. but isn't the driver target a
> dependency for the actual compilation target?  I seem to recall that all
> I did when I built it was to download it, change directory into the
> distribution, and type 'ant'.  It's pretty hard to ask for a simpler
> build process than that, I think.

Yes, exactly. You'd only need to use the "driver" target separately if
you only wanted substitution, but not the actual compile/package steps
for some reason.

-O

Friday, October 1, 2010, 7:39:31 PM, Kevin Grittner wrote:

> "Bremer, Gerd" <gerd.bremer@coremedia.com> wrote:
[snip]
> I suspect that if you pull official jars from the JDBC download
> page, nobody will find anything amiss if you keep Maven central
> current.

Although if someone wants to contribute for this purpose, it makes
much more sense to add Maven deployment to the Ant(?) script that is
used for making the releases. Then whoever does the release does the
release on Maven as well. It's safer and causes less delay.

--
Best regards,
 Daniel Dekany

On 2/10/2010 12:58 PM, Oliver Jowett wrote:
> Albert Kurucz wrote:
>> Why source files are not release after preprocessing?
>
> Because the substitutions that are needed are different depending on
> your build environment e.g. which JDBC version and JDK you are building
> for. The ant buildfile handles both detecting your build environment and
> performing suitable substitutions. Releasing multiple source
> distributions, each of which only works for one environment, where the
> only difference is in the 3-4 templated files - that'd be confusing and
> unnecessary when the build process already handles it, don't you think?

It would be pretty nice to generate source archives alongside the jars,
though I think putting them on the website would be somewhat excessive.
I'd mostly want the source jars to provide convenient debugging in
Netbeans, especially with Maven where it automagically finds the source
jars if they're there.

>> Java source files please for the non Ant users!
>
> I don't think we really support building the driver except via ant, it
> is something of a de-facto standard for building Java these days. (Ok,
> now the Maven people are going to yell at me ;-))

Consider yourself yelled at :-P

No, truly, there are things Ant's just better for, and a weird build
like this is probably one of them. Maven focuses on standardizing
builds, but that standardization comes at the cost of imposing some
inflexibility, so you land up needing to write Maven plugins or break
out to antrun.

Anyway, for an open source project it comes down to whatever's best for
the people doing the work, and anybody else can put up or shut up. If
you like Ant, and it's not keeping potential contributors away (which
I'm sure it isn't) then there's no reason not to use it.

I would like to point at the Maven Ant Tasks, though, as they're useful
when you want to spit Maven artifacts out of an Ant build (say, so they
can be pushed to Central).

http://maven.apache.org/ant-tasks/index.html

My Ant experience is limited as I jumped ship to Maven quite early on,
but I'd be willing to try to integrate Maven artifact generation into
the pgjdbc build if that'd make it easier to keep Central up to date.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

On 2/10/2010 2:40 PM, Daniel Dekany wrote:
> Friday, October 1, 2010, 7:39:31 PM, Kevin Grittner wrote:
>
>> "Bremer, Gerd"<gerd.bremer@coremedia.com>  wrote:
> [snip]
>> I suspect that if you pull official jars from the JDBC download
>> page, nobody will find anything amiss if you keep Maven central
>> current.
>
> Although if someone wants to contribute for this purpose, it makes
> much more sense to add Maven deployment to the Ant(?) script that is
> used for making the releases. Then whoever does the release does the
> release on Maven as well. It's safer and causes less delay.

http://maven.apache.org/ant-tasks/index.html

I'll give it a go if nobody else with more experience messing with Ant
and PgJDBC is volunteering.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Saturday, October 2, 2010, 9:24:42 AM, Craig Ringer wrote:

> On 2/10/2010 2:40 PM, Daniel Dekany wrote:
>> Friday, October 1, 2010, 7:39:31 PM, Kevin Grittner wrote:
>>
>>> "Bremer, Gerd"<gerd.bremer@coremedia.com>  wrote:
>> [snip]
>>> I suspect that if you pull official jars from the JDBC download
>>> page, nobody will find anything amiss if you keep Maven central
>>> current.
>>
>> Although if someone wants to contribute for this purpose, it makes
>> much more sense to add Maven deployment to the Ant(?) script that is
>> used for making the releases. Then whoever does the release does the
>> release on Maven as well. It's safer and causes less delay.
>
> http://maven.apache.org/ant-tasks/index.html

Or, a more relevant page:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

(AFAIR nowadays you will need a middleman, like sonatype.org for
example. The old way of doing this, which was that the Maven central
repo periodically rsync-ed itself with the public repo on your Web
server is now deprecated.)

> I'll give it a go if nobody else with more experience messing with Ant
> and PgJDBC is volunteering.
>
> --
> Craig Ringer
>
> Tech-related writing at http://soapyfrogs.blogspot.com/
>

--
Best regards,
 Daniel Dekany

Kris Jurka wrote on 01.10.2010 21:46:
> Aside from metadata changes, the key change that needs a new JDBC
> driver for a 9.0 server is the format of bytea data. You need to use
> the new JDBC driver or to adjust your server settings to return bytea
> data in the old format or you will silently get corrupt data.
>

I'm currently sticking to the 8.4 driver, as with the 9.0 driver, DatabaseMetaData.getIndexInfo() throws an exception
asit uses a SQL statement that is incompatible with PG 9.0 (I reported that about a week ago here on the list) 

Regards
Thomas

On 2/10/2010 4:30 PM, Daniel Dekany wrote:
> Saturday, October 2, 2010, 9:24:42 AM, Craig Ringer wrote:
>
>> On 2/10/2010 2:40 PM, Daniel Dekany wrote:
>>> Friday, October 1, 2010, 7:39:31 PM, Kevin Grittner wrote:
>>>
>>>> "Bremer, Gerd"<gerd.bremer@coremedia.com>   wrote:
>>> [snip]
>>>> I suspect that if you pull official jars from the JDBC download
>>>> page, nobody will find anything amiss if you keep Maven central
>>>> current.
>>>
>>> Although if someone wants to contribute for this purpose, it makes
>>> much more sense to add Maven deployment to the Ant(?) script that is
>>> used for making the releases. Then whoever does the release does the
>>> release on Maven as well. It's safer and causes less delay.
>>
>> http://maven.apache.org/ant-tasks/index.html
>
> Or, a more relevant page:
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>
> (AFAIR nowadays you will need a middleman, like sonatype.org for
> example. The old way of doing this, which was that the Maven central
> repo periodically rsync-ed itself with the public repo on your Web
> server is now deprecated.)

Aah, I didn't realize Sonatype were taking such a big role these days
with Nexus. Good - they seem to be pushing for quality control,
consistency, and at least some degree of security in their repository
management.

Thanks for the link.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Oliver,

Thanks for the info, so "ant driver" will create Java sources from the "templated files".
How does it know which JDBC version and which JDK version I have the desire to build for?
Is it in some config files or additional command line parameters for the "ant driver" command or some environment variables?

Releasing multiple separate sources for different versions of a product does not confusing me at all.
Having one source code for each target version might be more confusing.
Both ways have its own difficulties and their own benefits, and I am not trying to switch you.

Albert

Albert Kurucz wrote:

> How does it know which JDBC version and which JDK version I have the
> desire to build for?
> Is it in some config files or additional command line parameters for the
> "ant driver" command or some environment variables?

It looks at the ant ${java.specification.version} property.
You can see the details for yourself at
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/build.xml?rev=1.87&content-type=text/x-cvsweb-markup

-O

I created 6 artefact bundles and uploaded them to Sonatype staging repository as described on
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central. 

https://oss.sonatype.org/content/repositories/central_bundles-266
https://oss.sonatype.org/content/repositories/central_bundles-265
https://oss.sonatype.org/content/repositories/central_bundles-264
https://oss.sonatype.org/content/repositories/central_bundles-263
https://oss.sonatype.org/content/repositories/central_bundles-261
https://oss.sonatype.org/content/repositories/central_bundles-260

Currently they are in evaluation phase and not yet published on Maven Central.
* The most important class jars are the official jars from the JDBC download page.
* The javadoc jars are the same for jdbc3 and jdbc4, originating from the build/publicapi directory.
* The source jars are the same for jdbc3 and jdbc4, originating from the 'org' source directory without test classes in
org/postgresql/test.

-Gerd


-----Ursprüngliche Nachricht-----
Von: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov]
Gesendet: Freitag, 1. Oktober 2010 19:40
An: Bremer, Gerd; Albert Kurucz
Cc: pgsql-jdbc@postgresql.org
Betreff: Re: [JDBC] Upgrade to 9 questions

"Bremer, Gerd" <gerd.bremer@coremedia.com> wrote:

> I do not feel comfortable to upload artefacts from a project I
> haven't contributed to.

Keeping such a repository up-to-date with current jars could be
considered a contribution.

> Having latest releases in the Maven central repo is important, so
> I was surprised when I didn't find them.

It's not important to everyone; quite likely just to a minority.
Things in an open source project often get done by those
people to whom they are important.  I suspect that if you pull
official jars from the JDBC download page, nobody will find anything
amiss if you keep Maven central current.

-Kevin