[Monetdb-developers] JDBC liberation: use ant instead of make
Hi list, Tonight's testweb reveals that not a single JDBC test has run, due to incorrect packaging of the driver. I have always disliked the was the driver was built and packaged, but I think this time again, it is proven that `make` is too ancient for Java, or at least too clumpsy to deal with it. This is not only my personal opinion. That is, long ago other people already found out that make doesn't work that well with Java environments[1]. Although I understand the need to keep it 'simple'[2], I personally feel that fixing the current setup again to make it work is just another hack. From the very start of JDBC development, I used `ant`[1] to build the driver. Ant is, unlike make, a build tool geared towards Java projects, and the ant build scripts[3] that are currently in CVS have a much better understanding of the various files than make does. Just to name a few: - ant has multiple build targets for JDBC, XML:DB, MCL, etc. - ant date stamps each build - ant generates documentation when required - ant understands Java - ant builds jar files much more flexible. I am strongly in favour of using ant in the future to build Java related files. That is, let configure detect if ant is available or not, when Java is available. If not, don't build, or complain. I think most of our test platforms (especially since Sun and IRIX are RIP) have ant available (even Darwin has it!), as such availability of the build tools shouldn't be an issue. On a side note, testing Java on many platforms isn't that interesting, since the JVM itself has been tested on all platforms Sun supports. For JDBC, currently only endianness, timezone and charset are important. Since Darwin is both different-endian as well as in another timezone and using another charset by default, it is the only machine that really is interesting from a testing perspective, next to a windows machine and a linux machine in our neigbourhood. [1] http://ant.apache.org/ [2] that is, using tools known to those who deal with it [3] ant's build scripts are XML files called build.xml
Hi, sounds reaonable to me, hence, there's a green light from me ;-) Currently, we simply skip compiling (and hence testing) JDBC, in case there is no java; hence, we should then check for ant only in case java was found, and if there is java, but no ant, we simply skip JDBC (preferably, configure should tell that it did not find java or ant ...) Stefan On Fri, Dec 09, 2005 at 10:41:23AM +0100, Fabian Groffen wrote:
Hi list,
Tonight's testweb reveals that not a single JDBC test has run, due to incorrect packaging of the driver. I have always disliked the was the driver was built and packaged, but I think this time again, it is proven that `make` is too ancient for Java, or at least too clumpsy to deal with it.
This is not only my personal opinion. That is, long ago other people already found out that make doesn't work that well with Java environments[1]. Although I understand the need to keep it 'simple'[2], I personally feel that fixing the current setup again to make it work is just another hack. From the very start of JDBC development, I used `ant`[1] to build the driver. Ant is, unlike make, a build tool geared towards Java projects, and the ant build scripts[3] that are currently in CVS have a much better understanding of the various files than make does. Just to name a few:
- ant has multiple build targets for JDBC, XML:DB, MCL, etc. - ant date stamps each build - ant generates documentation when required - ant understands Java - ant builds jar files much more flexible.
I am strongly in favour of using ant in the future to build Java related files. That is, let configure detect if ant is available or not, when Java is available. If not, don't build, or complain. I think most of our test platforms (especially since Sun and IRIX are RIP) have ant available (even Darwin has it!), as such availability of the build tools shouldn't be an issue. On a side note, testing Java on many platforms isn't that interesting, since the JVM itself has been tested on all platforms Sun supports. For JDBC, currently only endianness, timezone and charset are important. Since Darwin is both different-endian as well as in another timezone and using another charset by default, it is the only machine that really is interesting from a testing perspective, next to a windows machine and a linux machine in our neigbourhood.
[1] http://ant.apache.org/ [2] that is, using tools known to those who deal with it [3] ant's build scripts are XML files called build.xml
------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
Niels and I more or less implemented this last weekend. An advantage of the system is that the SuSE machine appears not to have Ant, so the ever failing JDBC tests due to a misconfiguration there are over :) Autogen now knows a ant_<target> target, which calls ant with the given target. Like many autogen targets the ant_ target accepts a DIR property to set where to store the files during install. Because ant itself manages what files it needs, wants and produces, the FILES property of the ant_ target specifies which produced files in the build directory needs to be installed. On 09-12-2005 11:24:16 +0100, Stefan Manegold wrote:
Hi,
sounds reaonable to me, hence, there's a green light from me ;-)
Currently, we simply skip compiling (and hence testing) JDBC, in case there is no java; hence, we should then check for ant only in case java was found, and if there is java, but no ant, we simply skip JDBC (preferably, configure should tell that it did not find java or ant ...)
Stefan
participants (2)
-
Fabian Groffen -
Stefan Manegold