Обсуждение: I can't connect
Hi,
I installed debian 2.2r2 with _all_ the postgres-packages, I created a database and via psql I can do whatever I want
withthe DB. Now I'm trying to make a connection via a Java-program. I downloaded the jdbc-6.5-1.2.jar file and renamed
itto jdbc.jar and moved it to ~/jdk1.3/lib, set the CLASSPATH to ~/jdk1.3/lib and used a program, found in the
Deitel&DeitelJava book.
After that, I tried to make a connection to the database I created (testing) and I keep getting error-messages.
Can someone help me with this? I'm trying for 3 days now and still no luck.
Thanks,
Bart
--- program from Deitel & Deitel ---
import java.sql.*;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
public class TableDisplay extends JFrame
{
private Connection connection;
private JTable table;
public TableDisplay()
{
String url = "jdbc:odbc:testing"; // I also tried with <String url = "jdbc:postgres:testing";>
String username = "postgres";
String password = "notentered";
try
{
Class.forName("jdbc.Driver");
connection = DriverManager.getConnection(url, username, password);
}
catch (ClassNotFoundException cnfex)
{
System.err.println("Failed to load the JDBC/ODBC driver.");
cnfex.printStackTrace();
System.exit(1);
}
catch (SQLException sqlex)
{
System.err.println("Unable to connect to database.");
sqlex.printStackTrace();
}
. . . . . . . . .
Are you running postmaster with the -i option?
Bart <bart@alator.kotnet.org> on 03/21/2001 02:00:45 PM
To: pgsql-jdbc@postgresql.org
cc: (bcc: Dax Duskin/Evanston/ZSAssociates)
Subject: [JDBC] I can't connect
Hi,
I installed debian 2.2r2 with _all_ the postgres-packages, I created a database
and via psql I can do whatever I want with the DB. Now I'm trying to make a
connection via a Java-program. I downloaded the jdbc-6.5-1.2.jar file and
renamed it to jdbc.jar and moved it to ~/jdk1.3/lib, set the CLASSPATH to
~/jdk1.3/lib and used a program, found in the Deitel&Deitel Java book.
After that, I tried to make a connection to the database I created (testing) and
I keep getting error-messages.
Can someone help me with this? I'm trying for 3 days now and still no luck.
Thanks,
Bart
--- program from Deitel & Deitel ---
import java.sql.*;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
public class TableDisplay extends JFrame
{
private Connection connection;
private JTable table;
public TableDisplay()
{
String url = "jdbc:odbc:testing"; // I also tried with <String url =
"jdbc:postgres:testing";>
String username = "postgres";
String password = "notentered";
try
{
Class.forName("jdbc.Driver");
connection = DriverManager.getConnection(url, username,
password);
}
catch (ClassNotFoundException cnfex)
{
System.err.println("Failed to load the JDBC/ODBC driver.");
cnfex.printStackTrace();
System.exit(1);
}
catch (SQLException sqlex)
{
System.err.println("Unable to connect to database.");
sqlex.printStackTrace();
}
. . . . . . . . .
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Вложения
Bart: Try setting CLASSPATH to the path for the jar itself, not the directory in which you placed it. On Wed, 21 Mar 2001, Dax Duskin wrote: > Are you running postmaster with the -i option? > > Bart <bart@alator.kotnet.org> on 03/21/2001 02:00:45 PM > Subject: [JDBC] I can't connect > > I installed debian 2.2r2 with _all_ the postgres-packages, I created > a database and via psql I can do whatever I want with the DB. Now > I'm trying to make a connection via a Java-program. I downloaded the > jdbc-6.5-1.2.jar file and renamed it to jdbc.jar and moved it to > ~/jdk1.3/lib, set the CLASSPATH to ~/jdk1.3/lib and used a program, > found in the Deitel&Deitel Java book. After that, I tried to make a > connection to the database I created (testing) and I keep getting > error-messages. > > Can someone help me with this? I'm trying for 3 days now and still > no luck. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com
I think your url String should be
"jdbc:postgresql:testing"
and your Class.forName should be either
"org.postgresql.Driver" or "postgresql.Driver"
John L.
Quoting Bart <bart@alator.kotnet.org>:
> Hi,
>
> I installed debian 2.2r2 with _all_ the postgres-packages, I created a
> database and via psql I can do whatever I want with the DB. Now I'm
> trying to make a connection via a Java-program. I downloaded the
> jdbc-6.5-1.2.jar file and renamed it to jdbc.jar and moved it to
> ~/jdk1.3/lib, set the CLASSPATH to ~/jdk1.3/lib and used a program,
> found in the Deitel&Deitel Java book.
> After that, I tried to make a connection to the database I created
> (testing) and I keep getting error-messages.
>
> Can someone help me with this? I'm trying for 3 days now and still no
> luck.
>
> Thanks,
> Bart
>
>
> --- program from Deitel & Deitel ---
>
> import java.sql.*;
> import javax.swing.*;
> import java.awt.*;
> import java.awt.event.*;
> import java.util.*;
>
> public class TableDisplay extends JFrame
> {
> private Connection connection;
> private JTable table;
>
> public TableDisplay()
> {
> String url = "jdbc:odbc:testing"; // I also tried with <String url =
> "jdbc:postgres:testing";>
> String username = "postgres";
> String password = "notentered";
>
>
> try
> {
> Class.forName("jdbc.Driver");
> connection = DriverManager.getConnection(url, username, password);
> }
> catch (ClassNotFoundException cnfex)
> {
> System.err.println("Failed to load the JDBC/ODBC driver.");
> cnfex.printStackTrace();
> System.exit(1);
> }
> catch (SQLException sqlex)
> {
> System.err.println("Unable to connect to database.");
> sqlex.printStackTrace();
> }
> . . . . . . . . .
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to
> majordomo@postgresql.org)
>
-------------------------------------------------
This mail sent through IMP: www.netspace.net.au
It works. Thanks everyone!!! Bart
Quoting Bart <bart@alator.kotnet.org>:
> Hi,
>
> I installed debian 2.2r2 with _all_ the postgres-packages, I created a
> database and via psql I can do whatever I want with the DB. Now I'm
> trying to make a connection via a Java-program. I downloaded the
> jdbc-6.5-1.2.jar file and renamed it to jdbc.jar and moved it to
> ~/jdk1.3/lib, set the CLASSPATH to ~/jdk1.3/lib and used a program,
> found in the Deitel&Deitel Java book.
It can be put anywhere, not just ~/jdk1.3/lib...
> After that, I tried to make a connection to the database I created
> (testing) and I keep getting error-messages.
>
> Can someone help me with this? I'm trying for 3 days now and still no
> luck.
[snip]
> String url = "jdbc:odbc:testing"; // I also tried with
<String url =
> "jdbc:postgres:testing";>
"jdbc:postgresql:testing"
> String username = "postgres";
> String password = "notentered";
> Class.forName("jdbc.Driver");
Class.forName("org.postgresql.Driver");
Peter
--
Peter Mount peter@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Guys, tried to pull down the latest src and compile it but I can't. The build file seems to filter properties like MAJORVERISON, MINORVERSION etc with ant properties that don't exist? I've hard coded them all in my current SRC now, where are they supposed to come from? -mike
I'm having problems with this method at the moment on one DB.
I get a null pointer at the line... (1707 in the latest src)
tuple[3] = relKind.getBytes(); // table type
tracing it back it seems like this is because the switch statement above
gives a result of 'v' which from reading the comments is a) a VIEW table
type and b) not a valid option? (at least I think not valid, it's a
confusing long comment ;)).
I've patched it locally to add 'v' as a "VIEW" table type and it seems to
now run fine.
What to do?
-mike
On Fri, Mar 23, 2001 at 11:37:23AM +1100, Mike Cannon-Brookes wrote: > Guys, > > tried to pull down the latest src and compile it but I can't. The build file > seems to filter properties like MAJORVERISON, MINORVERSION etc with ant > properties that don't exist? > > I've hard coded them all in my current SRC now, where are they supposed to > come from? Try with following patch: http://www.l-t.ee/marko/pgsql/ant12.diff Does it help? (You need 'make clean' after applying.) -- marko
Mike Cannon-Brookes writes: > tried to pull down the latest src and compile it but I can't. The build file > seems to filter properties like MAJORVERISON, MINORVERSION etc with ant > properties that don't exist? You aren't running 'ant' directly, are you? Just run 'make'. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
At 14:21 25/03/01 +0200, Peter Eisentraut wrote: >Mike Cannon-Brookes writes: > > > tried to pull down the latest src and compile it but I can't. The build > file > > seems to filter properties like MAJORVERISON, MINORVERSION etc with ant > > properties that don't exist? > >You aren't running 'ant' directly, are you? Just run 'make'. Unless it's changed build.xml should have defaults for these, but make should then overide them. Running just ant should run with just the defaults. Peter
> > String url = "jdbc:odbc:testing"; // I also
> tried with
> <String url =
> > "jdbc:postgres:testing";>
>
> "jdbc:postgresql:testing"
I don't think so. Try
"jdbc:postgresql://computername/testing"
Peter Mount writes: > At 14:21 25/03/01 +0200, Peter Eisentraut wrote: > >Mike Cannon-Brookes writes: > > > > > tried to pull down the latest src and compile it but I can't. The build > > file > > > seems to filter properties like MAJORVERISON, MINORVERSION etc with ant > > > properties that don't exist? > > > >You aren't running 'ant' directly, are you? Just run 'make'. > > Unless it's changed build.xml should have defaults for these, but make > should then overide them. The version numbers used to be hardcoded into the source. I thought we were supposed to get rid of this. We could provide defaults like '0.0', but anything else is going to get us back to were we started. > > Running just ant should run with just the defaults. > > Peter > > -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
IMHO make should not be needed at all? I've hard coded the numbers into the Ant script now and it works fine. Java users like myself have brains that go "ooh, build.xml, let me run ant" to compile things. Why do we need make? (I'm sure there's a reason I can't see) -mike > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Peter Eisentraut > Sent: Monday, March 26, 2001 6:36 AM > To: Peter Mount > Cc: Mike Cannon-Brookes; pgsql-jdbc@postgresql.org > Subject: Re: Compiling > > > Peter Mount writes: > > > At 14:21 25/03/01 +0200, Peter Eisentraut wrote: > > >Mike Cannon-Brookes writes: > > > > > > > tried to pull down the latest src and compile it but I > can't. The build > > > file > > > > seems to filter properties like MAJORVERISON, MINORVERSION > etc with ant > > > > properties that don't exist? > > > > > >You aren't running 'ant' directly, are you? Just run 'make'. > > > > Unless it's changed build.xml should have defaults for these, but make > > should then overide them. > > The version numbers used to be hardcoded into the source. I thought we > were supposed to get rid of this. We could provide defaults like '0.0', > but anything else is going to get us back to were we started. > > > > > Running just ant should run with just the defaults. > > > > Peter > > > > > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Mike Cannon-Brookes writes: > Why do we need make? For consistency and to have a more powerful language. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Well Peter, I must say many would disagree with you there ;) I don't want to get into an ant vs make argument, but my main points are: 1) ant files are quickly becoming a standard for compiling almost all open source java projects 2) ant files are BUILT for java projects 3) currently we seem to have a build process that is 99% Ant and 1% make (for 4 substitutions). It seems unnecessarily complex to add make when we can remove it completely and not lose any functionality. On a related note, why does the JDBC driver need to track versions with the DB code? This seems pretty silly because it arbitrarily changes version without regard to what's changed in the JDBC driver. Why not split it off to have it's own versioning scheme? (This would get rid of any dependency on make as a nice consequence) -mike > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Peter Eisentraut > Sent: Tuesday, March 27, 2001 3:12 AM > To: Mike Cannon-Brookes > Cc: Peter Mount; pgsql-jdbc@postgresql.org > Subject: RE: Compiling > > > Mike Cannon-Brookes writes: > > > Why do we need make? > > For consistency and to have a more powerful language. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
On Tue, Mar 27, 2001 at 07:54:15AM +1000, Mike Cannon-Brookes wrote: > Well Peter, I must say many would disagree with you there ;) * NSHO about ant deleted * > 3) currently we seem to have a build process that is 99% Ant and 1% make > (for 4 substitutions). It seems unnecessarily complex to add make when we > can remove it completely and not lose any functionality. Peter E, Peter M: how about build.xml.in, where the needed substitutions are done in configure end-phase? I can prepare patch if this is acceptable. -- marko
Mike Cannon-Brookes writes: > 1) ant files are quickly becoming a standard for compiling almost all open > source java projects The nice thing about standards is that there are so many to choose from. At PostgreSQL, we use the GNU-style build system, which is already the "standard" for compiling almost all open source projects. One important aspect of this being a "system" is that it works uniformly. That means you can go to any subdirectory and run 'make; make install', etc., no matter if Ant, MakeMaker, or broken-Python-build-environment is running behind the scenes. > 2) ant files are BUILT for java projects > 3) currently we seem to have a build process that is 99% Ant and 1% make > (for 4 substitutions). It seems unnecessarily complex to add make when we > can remove it completely and not lose any functionality. > > On a related note, why does the JDBC driver need to track versions with the > DB code? This seems pretty silly because it arbitrarily changes version > without regard to what's changed in the JDBC driver. Why not split it off to > have it's own versioning scheme? (This would get rid of any dependency on > make as a nice consequence) For informational purposes, I suppose. We've had this discussion about splitting of the JDBC driver before, but the latest trend is to integrate everything as much as possible. Incidentally, I suggested that we default the version number to 0.0 if you're using Ant directly, but the end result of that might just be that we're going to have a bunch of 0.0 drivers being used out there, thus spreading an inconsistent software. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
At 18:56 27/03/01 +0200, Peter Eisentraut wrote: >Mike Cannon-Brookes writes: > > > 1) ant files are quickly becoming a standard for compiling almost all open > > source java projects > >The nice thing about standards is that there are so many to choose from. >At PostgreSQL, we use the GNU-style build system, which is already the >"standard" for compiling almost all open source projects. > >One important aspect of this being a "system" is that it works uniformly. >That means you can go to any subdirectory and run 'make; make install', >etc., no matter if Ant, MakeMaker, or broken-Python-build-environment is >running behind the scenes. I agree completely. > > 2) ant files are BUILT for java projects > > 3) currently we seem to have a build process that is 99% Ant and 1% make > > (for 4 substitutions). It seems unnecessarily complex to add make when we > > can remove it completely and not lose any functionality. > > > > On a related note, why does the JDBC driver need to track versions with the > > DB code? This seems pretty silly because it arbitrarily changes version > > without regard to what's changed in the JDBC driver. Why not split it > off to > > have it's own versioning scheme? (This would get rid of any dependency on > > make as a nice consequence) > >For informational purposes, I suppose. We've had this discussion about >splitting of the JDBC driver before, but the latest trend is to integrate >everything as much as possible. For support purposes. 99% of the emails I get people forget to say which versions of the backend & jdbc driver they are using. It would be a nightmare to try to keep track of each one if the schemes are different. Also, it should be easy (but isn't for some reason) that the 7.1 driver is for the 7.1 backend. If we had say 1.2 driver for 7.1 backend then that distinction is not as clear. >Incidentally, I suggested that we default the version number to 0.0 if >you're using Ant directly, but the end result of that might just be that >we're going to have a bunch of 0.0 drivers being used out there, thus >spreading an inconsistent software. Not a good idea for the same reason as above. Perhaps using build.xml.in is the way around this. for most of the other directories you still have to run configure before you can run make... PeterM
At 10:47 26/03/01 +1000, Mike Cannon-Brookes wrote: >IMHO make should not be needed at all? > >I've hard coded the numbers into the Ant script now and it works fine. Java >users like myself have brains that go "ooh, build.xml, let me run ant" to >compile things. > >Why do we need make? (I'm sure there's a reason I can't see) Now its an interface so that configure can run ant as part of the main build (ie compile, install, clean etc) PeterM
At 22:35 25/03/01 +0200, Peter Eisentraut wrote: >Peter Mount writes: > > > At 14:21 25/03/01 +0200, Peter Eisentraut wrote: > > >Mike Cannon-Brookes writes: > > > > > > > tried to pull down the latest src and compile it but I can't. The build > > > file > > > > seems to filter properties like MAJORVERISON, MINORVERSION etc with ant > > > > properties that don't exist? > > > > > >You aren't running 'ant' directly, are you? Just run 'make'. > > > > Unless it's changed build.xml should have defaults for these, but make > > should then overide them. > >The version numbers used to be hardcoded into the source. I thought we >were supposed to get rid of this. We could provide defaults like '0.0', >but anything else is going to get us back to were we started. Correct, the source (Driver.java.in) is setup in that way (ant inserts several parameters into it). It's just that build.xml has a couple of defaults in there to allow ant to run on it's own. Configure overides those values. Ideally they should be removed (I was thinking of after 7.1final was out) but we have to make the change slowly otherwise a lot of people will wonder why their calls to ant are failing, and I get enough emails as it is ;-) PeterM
At 13:04 27/03/01 +0200, Marko Kreen wrote: >On Tue, Mar 27, 2001 at 07:54:15AM +1000, Mike Cannon-Brookes wrote: > > Well Peter, I must say many would disagree with you there ;) > >* NSHO about ant deleted * > > > 3) currently we seem to have a build process that is 99% Ant and 1% make > > (for 4 substitutions). It seems unnecessarily complex to add make when we > > can remove it completely and not lose any functionality. > >Peter E, Peter M: how about build.xml.in, where the needed >substitutions are done in configure end-phase? I can prepare >patch if this is acceptable. For me that would be a good idea (remember there are three build.xml files) - it's just that I don't know enough about autoconf to do it myself :-) The main one for a build.xml.in would be the jdbc one, but ideally the one in the root would be the one ant should call. PeterM
On Thu, Mar 29, 2001 at 09:50:04AM +0100, Peter Mount wrote:
> At 13:04 27/03/01 +0200, Marko Kreen wrote:
> >On Tue, Mar 27, 2001 at 07:54:15AM +1000, Mike Cannon-Brookes wrote:
> > > 3) currently we seem to have a build process that is 99% Ant and 1% make
> > > (for 4 substitutions). It seems unnecessarily complex to add make when we
> > > can remove it completely and not lose any functionality.
> >
> >Peter E, Peter M: how about build.xml.in, where the needed
> >substitutions are done in configure end-phase? I can prepare
> >patch if this is acceptable.
>
> For me that would be a good idea (remember there are three build.xml files)
> - it's just that I don't know enough about autoconf to do it myself :-)
The .xml.in was not needed. I solved it using java.util.Properties
format file src/build.cfg.in where the parameters are specified.
Note: $DESTDIR works only with make. -Dinstall.directory overrides
build.cfg specified one.
Comments?
--
marko
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/build.xml pgsql/build.xml
--- pgsql.orig/build.xml Mon Mar 12 19:43:52 2001
+++ pgsql/build.xml Thu Mar 29 13:32:48 2001
@@ -18,6 +18,9 @@
<project name="postgresql" default="jar" basedir=".">
+ <!-- Load autoconfed properties. -->
+ <property file="src/build.cfg" />
+
<!--
This is the normal entry point. It builds first the
jdbc driver, then the extra tools.
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/configure.in pgsql/configure.in
--- pgsql.orig/configure.in Fri Mar 23 22:53:06 2001
+++ pgsql/configure.in Thu Mar 29 12:34:30 2001
@@ -32,6 +32,13 @@
AC_SUBST(VERSION)
AC_DEFINE_UNQUOTED(PG_VERSION, "$VERSION")
+changequote({, })
+VERSION_MAJOR=`echo $VERSION | sed 's/^\([0-9][0-9]*\)\..*\$/\1/'`
+VERSION_MINOR=`echo $VERSION | sed 's/^[0-9][0-9]*\.\([0-9][0-9]*\).*\$/\1/'`
+changequote([, ])
+AC_SUBST(VERSION_MAJOR)
+AC_SUBST(VERSION_MINOR)
+
unset CDPATH
AC_CANONICAL_HOST
@@ -414,6 +421,9 @@
[AC_MSG_RESULT(no)])
AC_SUBST(with_java)
+JAVA_DEST=$prefix/share/java
+AC_SUBST(JAVA_DEST)
+
dnl A note on the Kerberos and OpenSSL options:
dnl
dnl The user can give an argument to the option in order the specify
@@ -1179,6 +1189,7 @@
GNUmakefile
src/GNUmakefile
src/Makefile.global
+ src/build.cfg
src/backend/port/Makefile
],
[
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/contrib/retep/build.xml pgsql/contrib/retep/build.xml
--- pgsql.orig/contrib/retep/build.xml Tue Mar 27 12:27:11 2001
+++ pgsql/contrib/retep/build.xml Thu Mar 29 13:32:29 2001
@@ -14,6 +14,9 @@
<property name="package" value="uk/org/retep" />
<property name="jars" value="jars" />
+ <!-- Load autoconfed properties. -->
+ <property file="../../src/build.cfg" />
+
<!-- Some checks used to build dependent on the environment -->
<target name="checks">
<available property="jdk1.2+" classname="java.lang.ThreadLocal" />
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/src/GNUmakefile.in pgsql/src/GNUmakefile.in
--- pgsql.orig/src/GNUmakefile.in Mon Feb 12 19:29:27 2001
+++ pgsql/src/GNUmakefile.in Thu Mar 29 13:50:49 2001
@@ -40,4 +40,4 @@
-$(MAKE) -C bin $@
-$(MAKE) -C pl $@
-$(MAKE) -C test $@
- rm -f Makefile.port Makefile.global GNUmakefile
+ rm -f Makefile.port Makefile.global GNUmakefile build.cfg
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/src/build.cfg.in pgsql/src/build.cfg.in
--- pgsql.orig/src/build.cfg.in Thu Jan 1 03:00:00 1970
+++ pgsql/src/build.cfg.in Thu Mar 29 13:48:09 2001
@@ -0,0 +1,8 @@
+# Properties file for Ant
+
+fullversion=@VERSION@
+major=@VERSION_MAJOR@
+minor=@VERSION_MINOR@
+def_pgport=@default_port@
+install.directory=@JAVA_DEST@
+
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/src/interfaces/jdbc/Makefile pgsql/src/interfaces/jdbc/Makefile
--- pgsql.orig/src/interfaces/jdbc/Makefile Tue Mar 27 12:27:11 2001
+++ pgsql/src/interfaces/jdbc/Makefile Thu Mar 29 12:12:10 2001
@@ -12,20 +12,13 @@
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
-majorversion := $(shell echo $(VERSION) | sed 's/^\([0-9][0-9]*\)\..*$$/\1/')
-minorversion := $(shell echo $(VERSION) | sed 's/^[0-9][0-9]*\.\([0-9][0-9]*\).*$$/\1/')
-
-properties := -Dmajor=$(majorversion) -Dminor=$(minorversion) \
- -Dfullversion=$(VERSION) \
- -Ddef_pgport=$(DEF_PGPORT)
-
all:
- $(ANT) -buildfile $(top_srcdir)/build.xml $(properties)
+ $(ANT) -buildfile $(top_srcdir)/build.xml
install: installdirs
$(ANT) -Dinstall.directory=$(DESTDIR)$(datadir)/java \
-buildfile $(top_srcdir)/build.xml \
- install $(properties)
+ install
installdirs:
$(mkinstalldirs) $(DESTDIR)$(datadir)/java
diff -urNX /home/marko/misc/diff-exclude pgsql.orig/src/interfaces/jdbc/build.xml pgsql/src/interfaces/jdbc/build.xml
--- pgsql.orig/src/interfaces/jdbc/build.xml Tue Mar 27 12:27:11 2001
+++ pgsql/src/interfaces/jdbc/build.xml Thu Mar 29 13:31:43 2001
@@ -27,6 +27,9 @@
<property name="tablename" value="jdbctest" />
<property name="junit.ui" value="textui" />
+ <!-- Load autoconfed properties. -->
+ <property file="../../build.cfg" />
+
<!--
This is a simpler method than utils.CheckVersion
It defaults to jdbc1, but builds jdbc2 if the java.lang.Byte class is
Marko Kreen writes: > On Thu, Mar 29, 2001 at 09:50:04AM +0100, Peter Mount wrote: > > At 13:04 27/03/01 +0200, Marko Kreen wrote: > > >On Tue, Mar 27, 2001 at 07:54:15AM +1000, Mike Cannon-Brookes wrote: > > > > 3) currently we seem to have a build process that is 99% Ant and 1% make > > > > (for 4 substitutions). It seems unnecessarily complex to add make when we > > > > can remove it completely and not lose any functionality. > > > > > >Peter E, Peter M: how about build.xml.in, where the needed > > >substitutions are done in configure end-phase? I can prepare > > >patch if this is acceptable. > > > > For me that would be a good idea (remember there are three build.xml files) > > - it's just that I don't know enough about autoconf to do it myself :-) > > The .xml.in was not needed. I solved it using java.util.Properties > format file src/build.cfg.in where the parameters are specified. I think this is a good approach. Details can be worked out when we open up 7.2. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Quoting Peter Eisentraut <peter_e@gmx.net>: > Marko Kreen writes: > > > On Thu, Mar 29, 2001 at 09:50:04AM +0100, Peter Mount wrote: > > > At 13:04 27/03/01 +0200, Marko Kreen wrote: > > > >On Tue, Mar 27, 2001 at 07:54:15AM +1000, Mike Cannon-Brookes > wrote: > > > > > 3) currently we seem to have a build process that is 99% Ant and > 1% make > > > > > (for 4 substitutions). It seems unnecessarily complex to add > make when we > > > > > can remove it completely and not lose any functionality. > > > > > > > >Peter E, Peter M: how about build.xml.in, where the needed > > > >substitutions are done in configure end-phase? I can prepare > > > >patch if this is acceptable. > > > > > > For me that would be a good idea (remember there are three build.xml > files) > > > - it's just that I don't know enough about autoconf to do it myself > :-) > > > > The .xml.in was not needed. I solved it using java.util.Properties > > format file src/build.cfg.in where the parameters are specified. > > I think this is a good approach. Details can be worked out when we > open up 7.2. Agreed. Originally this was going to be a 7.2 feature anyhow, it just managed to get in to 7.1 ;-) Peter -- Peter Mount peter@retep.org.uk PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/