Thread: Status of JDBC Interface
Ok, after being a little quiet recently things are picking up (well at least for now). Anyhow, here's whats happening on the JDBC front: 1) ANT vs Make As someone (sorry forgotten your name) suggested using ANT instead of Make for building the driver. Well yesterday was pretty quiet here so I finally took the plunge and rewrote both the Makefile and its supporting class into ANT's xml build file. Lets just say this is definitely the way to go. The size of the Makefile & CheckVersions.java came to about 19K. build.xml is just over 2K and does exactly the same thing (and is faster). The real beauty about ANT is that it's platform independent as it's written in Java itself. ANT is part of the Apache Jakarta Project, and more details are available from http://jakarta.apache.org/ant/ So as of last night we now have two methods of compiling the driver: Method 1: Make make This builds and runs a test to see which version to build. If this fails then run one of: make jdbc1 This builds the JDBC1 driver make jdbc2 Build the JDBC2 standarddriver make enterprise Build the JDBC2 Enterprise driver make examples Build the JDBC1 & 2 Examples make examples2 Build the JDBC2 only examples make corba Build the corba example Method 2: ANT ant Builds the correct driver dependent on what JDK you have installed. ant clean Removes any built classes and jar files ant examples Builds the examples correctfor the JDK version in use I suggest we keep supporting both methods for now to see how people get on. CVS has an early version of build.xml, but I'm currently refining it today. 2) Versioning Ok, one problem in the past was keeping the driver uptodate with the correct version numbers. Before it was stored in three locations. Now back in October I moved this all into the org.postgresql.Driver class, so there was one location. Also as suggested on the Hackers list Make now extracts the version from Makefile.global. This works fine for Make, but there are two problems. First, ANT can't read this easily. This isn't that major, but the second one is. I've had reports that some people checkout just the interfaces, and not the entire source, so Makefile.global is not available. Hackers: Any ideas on how to solve this problem? If necessary I'll manually set it before release so it's not broken, but it needs sorting. 3) Web site www.retep.org.uk has now moved from Demon to Hub. However I'm having some problems still, mainly with my linux box at home. It's probably not going to be before next Wednesday before I get everything backup to speed. I'll try to get the updates on there, but can't guarantee it at the moment. 4) Email addresses As of this Friday (22nd December) the petermount@maidstone.gov.uk address will cease to exist. The peter@maidast.demon.co.uk one should be dead by now so obviously don't use that one either. Please only use the peter@retep.org.uk one for contacting me from now on. Thanks, Peter -- Peter Mount Enterprise Support Officer, Maidstone Borough Council Email: petermount@maidstone.gov.uk WWW: http://www.maidstone.gov.uk All views expressed within this email are not the views of Maidstone Borough Council
Peter Mount writes: > 1) ANT vs Make > I suggest we keep supporting both methods for now to see how people get on. If you're confident about ANT is suggest that you dump the make interface because otherwise you increase the possible failure scenarios at the install level alone in combinatorial ways. What's a bit sad about the JDBC subtree is that it doesn't follow the build system conventions in the rest of the tree. For example, I would really like to be able to do this: ./configure ... --with-java[=/usr/local/j2sdk1.3.0] make make install This wouldn't only make it easier on users, but many more people would perhaps be exposed to the fact that there's a JDBC driver in the tree at all. I have on and off had some ideas about autoconfiscating the JDBC build but I'm glad I didn't do it since this Ant thing seems to be much better. But it would still be desirable to have a make wrapper since that is what people are accustomed to. Btw., how does Ant choose the JDK it uses if I have three or four installed at random places? (This is perhaps yet another source of problems, if make and ant use different JDKs by default.) > 2) Versioning > one location. Also as suggested on the Hackers list Make now extracts the > version from Makefile.global. This works fine for Make, but there are two > problems. > > First, ANT can't read this easily. This isn't that major, but the second one > is. I've had reports that some people checkout just the interfaces, and not > the entire source, so Makefile.global is not available. Just checking out interfaces is not advertised AFAIK and it definitely doesn't work for anything but the JDBC driver. OTOH, nothing is stopping you from inventing your own versioning scheme for the driver only. Several other things in the tree do this as well (PyGreSql, PgAccess). -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
-- Peter Mount Enterprise Support Officer, Maidstone Borough Council Email: petermount@maidstone.gov.uk WWW: http://www.maidstone.gov.uk All views expressed within this email are not the views of Maidstone Borough Council > -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > Sent: Thursday, December 21, 2000 6:30 PM > To: Peter Mount > Cc: PostgreSQL Interfaces (E-mail); PostgreSQL Developers > List (E-mail) > Subject: Re: [HACKERS] Status of JDBC Interface > > > Peter Mount writes: > > > 1) ANT vs Make > > > I suggest we keep supporting both methods for now to see > how people get on. > > If you're confident about ANT is suggest that you dump the > make interface because otherwise you increase the possible > failure scenarios at the install level alone in combinatorial ways. My plan is to keep both for this release and then (assuming there's feedback about how ANT is working) to remove the current Makefile for the next one. > What's a bit sad about the JDBC subtree is that it doesn't follow the > build system conventions in the rest of the tree. For example, I would > really like to be able to do this: > > ./configure ... --with-java[=/usr/local/j2sdk1.3.0] > make > make install I did think about that but ran out of time. What would be nice would be for configure to either detect the presence of the JDK & ANT (with --with-java and --with-ant pairs) and then automatically call a cut down Makefile. ie: -- Begin Makefile -- all:ant clean:ant clean -- End Makefile -- The one big thing for ANT is that it makes the detection of the JDK/JVM version simple, so detecting the JDK/JVM version isn't required anywhere in the Makefiles. > This wouldn't only make it easier on users, but many more people would > perhaps be exposed to the fact that there's a JDBC driver in > the tree at all. Agreed. I still get emails from people asking for the source when it's included in the main source tree. > I have on and off had some ideas about autoconfiscating the > JDBC build but I'm glad I didn't do it since this Ant thing seems to be much better. > But it would still be desirable to have a make wrapper since > that is what people are accustomed to. Yes. I could replace Makefile now, but I wanted to see what everyones opinion on ANT was first. > Btw., how does Ant choose the JDK it uses if I have three or four > installed at random places? (This is perhaps yet another source of > problems, if make and ant use different JDKs by default.) There's the JAVA_HOME environment variable used by the JDK. Normally the JDK can work it out without the user setting it. I use it to switch between 1.1.8 & 1.2.2 (you also have to change PATH). Anyhow, you have set JAVA_HOME then ANT will use that for the compiler. There's also ANT_HOME but I'm running ok without that one set. PS: ANT works with both Sun's javac, jikes (IBM's compiler) and jvc (Micro$oft's Java/VisualJ++) The more I look into ANT's capabilities the more I like it. It's extensible (you can write your own class to implement new tasks) and it even has the ability to use CVS and apply patches on the fly, so if someone has CVS installed they only need to run: ant update and an update target (ANT's name for a rule in Make) then checks out the current source before building. > > 2) Versioning > > > one location. Also as suggested on the Hackers list Make > now extracts the > > version from Makefile.global. This works fine for Make, but > there are two > > problems. > > > > First, ANT can't read this easily. This isn't that major, > but the second one > > is. I've had reports that some people checkout just the > interfaces, and not > > the entire source, so Makefile.global is not available. > > Just checking out interfaces is not advertised AFAIK and it definitely > doesn't work for anything but the JDBC driver. I had an email from someone who said they did this (I didn't know you could before then) because of space reasons. Before 7.0 yes JDBC would be compileable but it has a link to Makefile.global now. > OTOH, nothing is stopping you from inventing your own > versioning scheme for the driver only. Several other things in the tree do this as well > (PyGreSql, PgAccess). True, but historically the JDBC versioning has matched that of the backend, and I think it makes it easier to say JDBC Driver v7.1 is for 7.1.x backends. This is especially as in this version DatabaseMetaData will not work with earlier version backends (uses INNER & OUTER joins). If I get chance today I'll see if I can get it to pull the versions out of Makefile.global. Peter