Skip site navigation (1) Skip section navigation (2)

Re: Ant Packaging - Was: building pgsql-interfaces...

From: Peter Mount <peter(at)retep(dot)org(dot)uk>
To: Christopher Cain <ccain(at)mhsoftware(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Ant Packaging - Was: building pgsql-interfaces...
Date: 2000-10-17 23:52:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
On Tue, 17 Oct 2000, Christopher Cain wrote:

> For what it's worth, I am very much in favor of migrating to Ant. Having worked
> with it in other packages, I have found it to be an order of magnitude better
> than Make for Java software. As mentioned, it is cleaner and much easier to
> work with than makefiles. Of course, I can say all of this because unlike like
> Peter, I have no idea what any of the complications are :-)

There's three complications really.

1: We need to get the current version number out of the source. This is
used by DatabaseMetaData for some methods, and the current official way is
to get it out of However, this is only in existence after
configure is run on the main source tree.

Prior to 7.1, this was done manually, and as there was several places to
do it, it was easily, and regularly missed.

2: The org.postgresql.Driver class is created dynamically. Partly to
include the version data, but also to include which implementation of
java.sql.Connection is needed for that particular version of the
driver. Ie, which one of the _three_ versions of the driver now in the
source - JDBC1.1, JDBC2 and JDBC2-Enterprise which match to either
JDK1.1.x, Java2SE and Java2EE respectively.

3: Currently make utilises a test class, utils.CheckVersion which is
compiliable on all JDK1.1 or later VM's and checks for the existence of
certain classes and parameters to check what true version of the JDK is in
existence. Make then uses this to build the correct version of
org.postgresql.Driver and the rest of the driver.

Now, some classes are only built for certain drivers. ie:

For the enterprise edition there are:

Unique to JDBC1 is org.postgresql.jdbc1.*

Unique to JDBC2 is org.postgresql.jdbc2.*
and some array implementation stuff I'm having trouble including from the
supplied patches (working on that one).

> I would like to get some feedback on the idea, however, as I really do think
> that Ant is a superior solution for Java projects. If there is any interest, I
> would certainly be willing to help Mark out in getting an Ant distro of the
> drivers up and running.

Make is dire for building Java projects, which is why I'd favour ANT if it
can deal with the three problems above. The last thing I want to see is
having to have three (possibly more) sets of source code where there are
lots of duplication, and we would loose the integrity of the driver pretty
fast (most of the driver is common to all versions).

Also, how platform independent is ANT? I currently test the builds under
Linux, and the various Windows entities (if you can call them an OS).


> Peter Mount wrote:
> > I'll look into Ant, but I can see some possible problems, especially as we
> > have 3 versions of driver now (JDBC1.1, JDBC2 and JDBC2enterprise), and I'm
> > checking the JDBC2.1 specification at the moment.
> Mark Dzmura wrote:
> > (( I offer as a suggestion that Peter/et al move to using the Java Apache
> > project's
> > "Ant" package for doing Java-only builds... It is so much faster and cleaner
> > to build under Ant (everything is compiled under a single JVM) and
> > maintanence
> > of the build.xml file is so much cleaner than hopeless makefiles...
> >
> > If there is interest, I will take a stab at creating a build.xml for the
> > JDBC driver...))

Peter T Mount peter(at)retep(dot)org(dot)uk
PostgreSQL JDBC Driver
Java PDF Generator

In response to


pgsql-interfaces by date

Next:From: Marc RassbachDate: 2000-10-17 23:54:34
Subject: Re: 2 computers 1hd 2 postgres daemons. Is it possible?]
Previous:From: Luc BouchardDate: 2000-10-17 21:35:19
Subject: Re: RE: 2 computers 1hd 2 postgres daemons. Is it possib

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group