Thread: Re: [PATCHES] Ant configuration
I don't like this patch. If anything I think we should remove the dependency on ANT, not remove the dependency on make. By requiring ANT, we provide yet another hurdle for someone wanting to use JDBC with postgres. I would prefer that the build environment be the same for the database as for the jdbc code. Anything that makes it more difficult to download the source and get going with it is a negative in my opinion. And from my perspective requiring the download of an additional tool (ANT in this case) makes it more difficult. I already know that some binary distributions of postgres do not include JDBC simply because it is too complex to get ANT installed in their build environment. (complex perhaps isn't the right word, but it is more work than they are willing to put in for a small feature of postgres). thanks, --Barry Marko Kreen wrote: > I dusted a old patch that integrates Ant better with > autoconf. It creates a file src/ant.cfg.in to pass > autoconf parameters to Ant. Now Ant can be used directly, > without going through Makefile. > > 'install.directory' is still passed in Makefile to keep > DESTDIR working. > >
On Wed, Oct 17, 2001 at 01:23:13PM -0700, Barry Lind wrote: > I don't like this patch. If anything I think we should remove the > dependency on ANT, not remove the dependency on make. > > By requiring ANT, we provide yet another hurdle for someone wanting to > use JDBC with postgres. I would prefer that the build environment be > the same for the database as for the jdbc code. > > Anything that makes it more difficult to download the source and get > going with it is a negative in my opinion. And from my perspective > requiring the download of an additional tool (ANT in this case) makes it > more difficult. I have no strong feelings about current situation, I simply made it more flexible. About changing it, you should consult JDBC maintainers first, maybe they have some good reason why its so... > I already know that some binary distributions of postgres do not include > JDBC simply because it is too complex to get ANT installed in their > build environment. (complex perhaps isn't the right word, but it is more > work than they are willing to put in for a small feature of postgres). JDBC driver is simply a .jar file, I think it should be more easily downloadable from main website. (JDBC1/JDBC2 edition...) -- marko
> On Wed, Oct 17, 2001 at 01:23:13PM -0700, Barry Lind wrote: > > I don't like this patch. If anything I think we should remove the > > dependency on ANT, not remove the dependency on make. > > > > By requiring ANT, we provide yet another hurdle for someone wanting to > > use JDBC with postgres. I would prefer that the build environment be > > the same for the database as for the jdbc code. > > > > Anything that makes it more difficult to download the source and get > > going with it is a negative in my opinion. And from my perspective > > requiring the download of an additional tool (ANT in this case) makes it > > more difficult. > > I have no strong feelings about current situation, I simply made > it more flexible. About changing it, you should consult JDBC > maintainers first, maybe they have some good reason why its > so... Barry and Dave are the jdbc maintainers now and I think there is general consensus that we want to get away from Ant if possible. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Given that ant is (or is becoming) the defacto standard for building
java apps I am reluctant to remove it. A number of projects simply
include the ant jar in the download.
Dave
-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Barry Lind
Sent: October 17, 2001 4:23 PM
To: Marko Kreen
Cc: pgsql-patches@postgresql.org; pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] [PATCHES] Ant configuration
I don't like this patch. If anything I think we should remove the
dependency on ANT, not remove the dependency on make.
By requiring ANT, we provide yet another hurdle for someone wanting to
use JDBC with postgres. I would prefer that the build environment be
the same for the database as for the jdbc code.
Anything that makes it more difficult to download the source and get
going with it is a negative in my opinion. And from my perspective
requiring the download of an additional tool (ANT in this case) makes it
more difficult.
I already know that some binary distributions of postgres do not include
JDBC simply because it is too complex to get ANT installed in their
build environment. (complex perhaps isn't the right word, but it is more
work than they are willing to put in for a small feature of postgres).
thanks,
--Barry
Marko Kreen wrote:
> I dusted a old patch that integrates Ant better with autoconf. It
> creates a file src/ant.cfg.in to pass autoconf parameters to Ant. Now
> Ant can be used directly, without going through Makefile.
>
> 'install.directory' is still passed in Makefile to keep DESTDIR
> working.
>
>
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Marko, I am one of the jdbc maintainers. That is why I posted this to the list as I did. I wanted to see if there was concensus on this issue one way or the other. In looking at your patch, I don't have any problems with it technically, but I would hate to have it applied, only to remove the entire functionality in the future (although I guess that doesn't really hurt anything). I do appreciate you taking your time to put this patch together and submitting it. That is how open source projects work after all. I just want to make sure there is agreement that this is the right direction people want the jdbc driver to go. thanks, --Barry Marko Kreen wrote: > On Wed, Oct 17, 2001 at 01:23:13PM -0700, Barry Lind wrote: > >>I don't like this patch. If anything I think we should remove the >>dependency on ANT, not remove the dependency on make. >> >>By requiring ANT, we provide yet another hurdle for someone wanting to >>use JDBC with postgres. I would prefer that the build environment be >>the same for the database as for the jdbc code. >> >>Anything that makes it more difficult to download the source and get >>going with it is a negative in my opinion. And from my perspective >>requiring the download of an additional tool (ANT in this case) makes it >>more difficult. >> > > I have no strong feelings about current situation, I simply made > it more flexible. About changing it, you should consult JDBC > maintainers first, maybe they have some good reason why its > so... > > >>I already know that some binary distributions of postgres do not include >>JDBC simply because it is too complex to get ANT installed in their >>build environment. (complex perhaps isn't the right word, but it is more >>work than they are willing to put in for a small feature of postgres). >> > > JDBC driver is simply a .jar file, I think it should be more > easily downloadable from main website. (JDBC1/JDBC2 edition...) > >
On Wed, Oct 17, 2001 at 07:37:27PM -0700, Barry Lind wrote: > > I am one of the jdbc maintainers. That is why I posted this to the list > as I did. I wanted to see if there was concensus on this issue one way > or the other. In looking at your patch, I don't have any problems with > it technically, but I would hate to have it applied, only to remove the > entire functionality in the future (although I guess that doesn't really > hurt anything). Ok. > I do appreciate you taking your time to put this patch together and > submitting it. That is how open source projects work after all. I just > want to make sure there is agreement that this is the right direction > people want the jdbc driver to go. No problem. About Ant->Makefile thing I still cant convince myself that this is a project worth doing. Ant's only downside is that user needs to set it up separately and its not a very easy thing to do. And at the time of Ant 1.1 this was a real problem (for me at least) as Ant had rather obscure compatibility problems with various XML libs and finally I decided that 'Ant sucks'. But with Ant 1.3/1.4 they seems to have that kind of a problems under control and at least I have not had any problems with it since then. But it seems to me that Ant has a positive side too: * People with Java background probably know Ant better that 'make'. Ant seems to become 'build tool of choice' in Java world. * When Ant is set up, it takes care of all local Java environment, so we in PostgreSQL source do not need to bother about it. * In Ant the build file will be much less complex than a Makefile with same functionality. And same time in Ant it is much easier to check local Java internal setup. Basically I am able to do it, I have managed moderately sized Java project with Makefile, but it was not nice. You could check JDBC Makefile from Jan 2001 - it is quite messy. -- marko
Barry Lind writes: > I don't like this patch. If anything I think we should remove the > dependency on ANT, not remove the dependency on make. The use of Ant originally seemed attractive because it would solve the detection of the jdk version, the portable invocation of the compiler, and the dependency generation. However, I must currently consider this experiment a failure, because for each problem Ant solves it introduces a load of worse problems into the system. Thus, if we can agree to work out a configure/make-based system for the next release I would be very much for it. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Marko, > > But it seems to me that Ant has a positive side too: I agree that there are positive reasons to use Ant (that is why it was done in the first place). It is just that in retrospect, I don't believe the pluses outweigh the minuses. > > * People with Java background probably know Ant better that > 'make'. Ant seems to become 'build tool of choice' in > Java world. Perhaps, but I'm not convinced that either of these arguments is true. I have seen make used by more projects than ant, and a developer building postgres from source, certainly needs to be familiar with make. > > * When Ant is set up, it takes care of all local Java > environment, so we in PostgreSQL source do not need > to bother about it. I'm not sure what you mean here. Can you provide an example? > > * In Ant the build file will be much less complex > than a Makefile with same functionality. And same > time in Ant it is much easier to check local > Java internal setup. > I agree that this is true, but I think a much better job can be done to minimize the added complexity. I have looked at the old makefile and it was quite complex. But I have ideas on how to reduce that complexity. Basically I want to trade off a little more complexity on the part of the developers of jdbc, for less complexity for users to install and build. thanks, --Barry
* Peter Eisentraut <peter_e@gmx.net> wrote: | | The use of Ant originally seemed attractive because it would solve the | detection of the jdk version, the portable invocation of the compiler, and | the dependency generation. However, I must currently consider this | experiment a failure, because for each problem Ant solves it introduces a | load of worse problems into the system. Thus, if we can agree to work out | a configure/make-based system for the next release I would be very much | for it. What are the pro and cons for each approach ? Would it be unfeasible to include the ant binary in the distribution or is there other problems as well ? If we use make I guess we could use jikes to generate dependency files for make, but that does give use much as we then will require jikes for developers. Another alternative is make clean or manual approaches. I would say that we have two primary concerns here : 1. A build process that JDBC developers find convenient and productive to work with. 2. A build process that the users find convenient. Downloading things like Ant is not helping them. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
The one issue I have with a non ant based build system is that it makes it difficult to build the driver on a windows machine. Currently I can build the driver on windows without using cygwin What problems does ant present? Dave -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Peter Eisentraut Sent: October 18, 2001 5:04 PM To: Barry Lind Cc: Marko Kreen; pgsql-patches@postgresql.org; pgsql-jdbc@postgresql.org Subject: Re: [JDBC] [PATCHES] Ant configuration Barry Lind writes: > I don't like this patch. If anything I think we should remove the > dependency on ANT, not remove the dependency on make. The use of Ant originally seemed attractive because it would solve the detection of the jdk version, the portable invocation of the compiler, and the dependency generation. However, I must currently consider this experiment a failure, because for each problem Ant solves it introduces a load of worse problems into the system. Thus, if we can agree to work out a configure/make-based system for the next release I would be very much for it. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
> Barry Lind writes:
>
> > I don't like this patch. If anything I think we should remove the
> > dependency on ANT, not remove the dependency on make.
>
> The use of Ant originally seemed attractive because it would solve the
> detection of the jdk version, the portable invocation of the compiler, and
> the dependency generation. However, I must currently consider this
> experiment a failure, because for each problem Ant solves it introduces a
> load of worse problems into the system. Thus, if we can agree to work out
> a configure/make-based system for the next release I would be very much
> for it.
I think I can safely at to TODO:
JDBC
o Move from Ant to Make builds
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > * In Ant the build file will be much less complex > > than a Makefile with same functionality. And same > > time in Ant it is much easier to check local > > Java internal setup. > > I agree that this is true, but I think a much better job can be done to > minimize the added complexity. I have looked at the old makefile and it > was quite complex. But I have ideas on how to reduce that complexity. > > Basically I want to trade off a little more complexity on the part of > the developers of jdbc, for less complexity for users to install and build. I don't mind either way really, but I don't see why the makefile should need to be so complex. One option is also since Postgresql uses configure to build, we can use configure to help us detect whatever we need to if --with-java is turned on and set suitable options/paths etc in the makefile. That said I haven't really looked at the current build process for the driver. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com tom@nooper.com - Testing - http://nooper.co.jp/labs
* "Dave Cramer" <Dave@micro-automation.net> wrote: | | The one issue I have with a non ant based build system is that it makes | it difficult to build the driver on a windows machine. I think is a valid concern, since a lot of clients presumably will be running on other architectures. Maybe a twofold solution ? 1. a very simple make file that doesn't care about dependencies and such. 2. ant as an alternative for developers and users of other platforms. And I think more and more projects are migrating towards using Ant. Even I have done so after 10 years of using make ;-) -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
* Bruce Momjian <pgman@candle.pha.pa.us> wrote: | | I think I can safely at to TODO: | | JDBC | o Move from Ant to Make builds I don't think there is consesus over at the JDBC list yet. We need to get all the pros/cons for both solutions on the table first. Make is not neccesarily better than Ant, I would think a combination would work best. Because then Mac and Windows users could use Ant to compile their JDBC driver, while the compilation of the server on Unices would work seamlessly. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
OK, TODO item removed. > * Bruce Momjian <pgman@candle.pha.pa.us> wrote: > | > | I think I can safely at to TODO: > | > | JDBC > | o Move from Ant to Make builds > > I don't think there is consesus over at the JDBC list yet. We need to get > all the pros/cons for both solutions on the table first. Make is not > neccesarily better than Ant, I would think a combination would work best. > Because then Mac and Windows users could use Ant to compile their JDBC > driver, while the compilation of the server on Unices would work > seamlessly. > > -- > Gunnar R?nning - gunnar@polygnosis.com > Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Dave Cramer writes: > The one issue I have with a non ant based build system is that it makes > it difficult to build the driver on a windows machine. That is a valid concern that we're going to have to think about before we move to another method. > What problems does ant present? * Ant needs to be installed. Of course this is not that much of a problem because you can simply install it. However, in automated build environments this might not be so easy, so people are just going to opt to leave out the JDBC driver. * Ant doesn't provide an exit status; you have to watch the build to see if it works. This is unacceptable. * Ant is buggy. We've had numerous reports of people having trouble with it for no apparent reason. I can also confirm from my own experience that numerous things don't seem to work the way they should work. * In numerous attempts I have failed to convince Ant to place the built files in a tree different from the source tree. This really makes it a pain to build for multiple architectures (in Java, architecture = different jdk). * Ant doesn't support gcj last I checked. This is a real tragedy because gcj is the only free(tm) Java compiler available that seems to have a real future. Ant doesn't support Kaffe very well, btw. * The Ant language is not nearly as powerful as the stuff you can do in Makefiles. * Ant is, well, different. I have personally spent a lot of effort to make all parts of PostgreSQL build the same way. Every new language has to reinvent configuration and build management: Perl MakeMaker -- total junk, Python distutils -- no thanks, Tcl -- well, at least they had the right idea. Ant -- one more thing to go wrong. Currently, everything you want to switch and change about the build of PostgreSQL you communicate to the configure script. How do you change the Java compiler? Good question -- not even the Ant manual can answer that because it depends on your particular distribution. The problem is that Ant is a completely new and different tool that we have to deal with, but it doesn't actually solve a problem that hasn't been solved already. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
* Peter Eisentraut <peter_e@gmx.net> wrote:
|
| * Ant needs to be installed. Of course this is not that much of a
| problem because you can simply install it. However, in automated build
| environments this might not be so easy, so people are just going to opt to
| leave out the JDBC driver.
This can be solved by including the ant binaries.
| * Ant doesn't provide an exit status; you have to watch the build to see
| if it works. This is unacceptable.
Hmm. Anybody with a solution here ?
|
| * In numerous attempts I have failed to convince Ant to place the built
| files in a tree different from the source tree. This really makes it a
| pain to build for multiple architectures (in Java, architecture =
| different jdk).
<javac srcdir="${src}"
destdir="${build}"
classpath="xyz.jar"
debug="on"
/>
Is that what you want ?
|
| * Ant doesn't support gcj last I checked. This is a real tragedy because
| gcj is the only free(tm) Java compiler available that seems to have a real
| future. Ant doesn't support Kaffe very well, btw.
It does support it now according to the documentation. I think open source
jikes has a better future as a compiler, but it is not free in the GNU sense.
| * The Ant language is not nearly as powerful as the stuff you can do in
| Makefiles.
Well, make doesn't solve the build problems for Java. Ant is made to remedy the
problems with make and create and easier to use build tool for Java apps. The
adoption rate of Ant suggests that the developers have been doing something
right ;-)
|
| * Ant is, well, different. I have personally spent a lot of effort to
| make all parts of PostgreSQL build the same way. Every new language has
| to reinvent configuration and build management: Perl MakeMaker -- total
| junk, Python distutils -- no thanks, Tcl -- well, at least they had the
| right idea. Ant -- one more thing to go wrong. Currently, everything you
| want to switch and change about the build of PostgreSQL you communicate to
| the configure script. How do you change the Java compiler? Good question
| -- not even the Ant manual can answer that because it depends on your
| particular distribution.
From the Ant manual :
It is possible to use different compilers. This can be selected with
the "build.compiler" property.
|
| The problem is that Ant is a completely new and different tool that we
| have to deal with, but it doesn't actually solve a problem that hasn't
| been solved already.
It solves some of the problems with make and it runs easily on platforms
like Windows and Mac.
When Ant 2.0 comes it will be a even more general task/build system as it will
allow for scheduling ala cron as well. But that is off-topic ;-)
--
Gunnar Rønning - gunnar@polygnosis.com
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
Dave Cramer writes: > The one issue I have with a non ant based build system is that it > makes it difficult to build the driver on a windows machine. That is a valid concern that we're going to have to think about before we move to another method. > What problems does ant present? * Ant needs to be installed. Of course this is not that much of a problem because you can simply install it. However, in automated build environments this might not be so easy, so people are just going to opt to leave out the JDBC driver. I'm sure we can use the Makefile to install the ant jar. * Ant doesn't provide an exit status; you have to watch the build to see if it works. This is unacceptable. Hmmm... I will look into this * Ant is buggy. We've had numerous reports of people having trouble with it for no apparent reason. I can also confirm from my own experience that numerous things don't seem to work the way they should work. I find this a little hard to believe given the number of projects which use ant as a primary build tool. jarkarta.apache.org for instance * In numerous attempts I have failed to convince Ant to place the built files in a tree different from the source tree. This really makes it a pain to build for multiple architectures (in Java, architecture = different jdk). I think this can be overcome. I have had no problems with this. * Ant doesn't support gcj last I checked. This is a real tragedy because gcj is the only free(tm) Java compiler available that seems to have a real future. Ant doesn't support Kaffe very well, btw. There are a number of free compilers, sun's is free, ibm's is free.... * The Ant language is not nearly as powerful as the stuff you can do in Makefiles. No comment .... I am Make challenged, but Ant is pretty comprehensive... * Ant is, well, different. I have personally spent a lot of effort to make all parts of PostgreSQL build the same way. Every new language has to reinvent configuration and build management: Perl MakeMaker -- total junk, Python distutils -- no thanks, Tcl -- well, at least they had the right idea. Ant -- one more thing to go wrong. Currently, everything you want to switch and change about the build of PostgreSQL you communicate to the configure script. How do you change the Java compiler? Good question -- not even the Ant manual can answer that because it depends on your particular distribution. Change the $JAVA_HOME environment variable AFAIK The problem is that Ant is a completely new and different tool that we have to deal with, but it doesn't actually solve a problem that hasn't been solved already. Well, this is a little philosophical, but my current focus is java, and ant is the de-facto standard for building java programs, so I guess I'm biased towards it. One thing it does solve is the ability to resolve inter-dependancies automatically. I have had builds which can only be built by ant, or by building the entire source tree at once. This is one feature which is usefull. As for a solution. My opinion is that we should support both. There seems to be enough interested parties to support both build tools. For the folks that want a Makefile, they can support it. If someone wants to support the build.xml file, then we should encourage it. I suspect that one of them will become obsolete on it's own. Dave
* "Dave Cramer" <Dave@micro-automation.net> wrote:
|
|
| There seems to be enough interested parties to support both build tools.
| For the folks that want a Makefile, they can support it. If someone
| wants to support the build.xml file, then we should encourage it. I
| suspect that one of them will become obsolete on it's own.
I think that would be the best as well for time being. Don't remove ant
support as that is very useful for the people working on the JDBC code, and
add standard make files for building the system. Make itself is not designed
to work with a language like Java, so you need third party tools to handle
dependencies.
Gunnar
--
Gunnar Rønning - gunnar@polygnosis.com
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 20-Oct-2001 Gunnar R�nning wrote:
>| * Ant doesn't provide an exit status; you have to watch the build to see
>| if it works. This is unacceptable.
>
> Hmm. Anybody with a solution here ?
Actuall, it does.
Example:
[wolpert@wolpert configTest]$ ant build
Buildfile: build.xml
prepare:
build:
BUILD SUCCESSFUL
Total time: 2 seconds
[wolpert@wolpert configTest]$ echo $?
0
[wolpert@wolpert configTest]$ ant build
Buildfile: build.xml
prepare:
build:
[javac] Compiling 1 source file to /home/wolpert/test/configTest/classes
[javac] /home/wolpert/test/configTest/src/GetAll.java:25: ';' expected
[javac] jdo.setDatabaseName("configTest");
[javac] ^
[javac] /home/wolpert/test/configTest/src/GetAll.java:24: cannot resolve
symbol
[javac] symbol : class fds
[javac] location: class GetAll
[javac] jdo.setConfiguration("/database.xml");fds
[javac] ^
[javac] /home/wolpert/test/configTest/src/GetAll.java:25: jdo is already
defined in getDatabase()
[javac] jdo.setDatabaseName("configTest");
[javac] ^
[javac] 3 errors
BUILD FAILED
/home/wolpert/test/configTest/build.xml:35: Compile failed, messages should
have been provided.
Total time: 4 seconds
[wolpert@wolpert configTest]$ echo $?
1
[wolpert@wolpert configTest]$
Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE71FvwiysnOdCML0URAqiRAJ4g8TL2aY9fAj25JzOw+mabnBG8PACggEOK
xQOWn7giK++ZRDAsfyDtzsE=
=M4Ld
-----END PGP SIGNATURE-----
Gunnar Rønning writes:
> | * In numerous attempts I have failed to convince Ant to place the built
> | files in a tree different from the source tree. This really makes it a
> | pain to build for multiple architectures (in Java, architecture =
> | different jdk).
>
> <javac srcdir="${src}"
> destdir="${build}"
> classpath="xyz.jar"
> debug="on"
> />
>
>
> Is that what you want ?
Yes, but ant refused to recognize the srcdir as absolute and thinks it's
relative to the build dir. (Or at least it was something stupid like
that; it's been a while.)
> >From the Ant manual :
>
> It is possible to use different compilers. This can be selected with
> the "build.compiler" property.
Yeah, but how do you set the "build.compiler" property? This requires
pretty advanced knowledge.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Ned Wolpert writes: > Actuall, it does. peter ~$ ant -version Ant version 1.3 compiled on March 22 2001 peter ~$ echo $? 0 peter ~$ ant Buildfile: build.xml does not exist! Build failed peter ~$ echo $? 0 -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 23-Oct-2001 Peter Eisentraut wrote:
> Gunnar R�nning writes:
>> | * In numerous attempts I have failed to convince Ant to place the built
>> | files in a tree different from the source tree. This really makes it a
>> | pain to build for multiple architectures (in Java, architecture =
>> | different jdk).
>>
>> <javac srcdir="${src}"
>> destdir="${build}"
>> classpath="xyz.jar"
>> debug="on"
>> />
>>
>>
>> Is that what you want ?
>
> Yes, but ant refused to recognize the srcdir as absolute and thinks it's
> relative to the build dir. (Or at least it was something stupid like
> that; it's been a while.)
That should work fine. I've been doing that since Ant version 1.3. Do you have
a specific case that doesn't work? (You can always specify absolute paths in
the properties, if you like...)
>> >From the Ant manual :
>>
>> It is possible to use different compilers. This can be selected with
>> the "build.compiler" property.
>
> Yeah, but how do you set the "build.compiler" property? This requires
> pretty advanced knowledge.
You can either set-it in the build.xml file via a property tag
<property name="build.compiler" value="jikes"/>
or during the startup of ant using the -D flag. (set the ANT_OPTS var to
"-Dbuild.compiler=jikes" in your environment before running ant)
Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE71etAiysnOdCML0URAkk6AJ9Op2uOIfbd4UokyhsJqS1/S4ZgjQCeJZd4
vmRbTwuQadIuhyez/86OpF0=
=xk1y
-----END PGP SIGNATURE-----
where do I put the postgresql.jar to connect StarOffice to Postgres? I have it in the /usr/java/jdk1.3/lib directory on the client machine (the one running staroffice) Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
It has to go into the staroffice/lib directory if you are using staroffice6. I quickly tried it and it fails due to a nullpointer exception. It is on my todo list to figure out. If you get it working let me know Dave -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of tony Sent: October 24, 2001 4:58 AM To: pgsql-jdbc@postgresql.org Subject: [JDBC] StarOffice question where do I put the postgresql.jar to connect StarOffice to Postgres? I have it in the /usr/java/jdk1.3/lib directory on the client machine (the one running staroffice) Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html ---------------------------(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
I'm afraid you should use ODBC instead of JDBC with StarOffice. See http://odbc.postgresql.org I have just checked it out, and have been unable to find what I had found about StarOffice. Hope that helps. Antonio tony wrote: > where do I put the postgresql.jar to connect StarOffice to Postgres? > > I have it in the /usr/java/jdk1.3/lib directory on the client machine > (the one running staroffice) > > Cheers > > Tony Grant > > -- > RedHat Linux on Sony Vaio C1XD/S > http://www.animaproductions.com/linux2.html > Macromedia UltraDev with PostgreSQL > http://www.animaproductions.com/ultra.html > > ---------------------------(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 Wed, 2001-10-24 at 12:53, Dave Cramer wrote: > It has to go into the staroffice/lib directory if you are using > staroffice6. > > I quickly tried it and it fails due to a nullpointer exception. It is on > my todo list to figure out. > > If you get it working let me know The message says "unable to load driver..." I would put StarOffice compatibility way up in the top 5... Cheers Tony -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html