Re: Existence of a database?
On Wed, 19 May 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: Use antcall to call the target with the db specific properties, this way you can merge the postresql and the mysql targets. No. Use Ant 1.6+ and macrodef. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Existence of a database?
On Wed, 19 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote:
I wonder if it possible to group tasks and invoke them as a function
or a method call.
Rather as a macro. Let me see whether I can find a macrodef
solution for you.
The target running the test would be easy:
macrodef name=rundbtest
attribute name=dbtype/
sequential
delete file=./input/db/db.properties/
echo message=@{dbtype} available/
copy file=./input/db/@{dbtype}.properties
tofile=./input/db/db.properties/
junit printsummary=yes fork=no haltonfailure=yes
sysproperty key=runLen value=100/
classpath refid=tests.classpath/
formatter type=plain usefile=false/
test name=org.apache.log4j.db.FullCycleDBTest /
/junit
/sequential
/macrodef
and
target name=mysql depends=mysqlCheck, build if=mysql-present
rundbtest dbtype=mysql/
/target
target name=postgresql depends=postgresqlCheck, build
if=postgresql-present
rundbtest dbtype=postgresql/
/target
The checking part may be more difficult than the tests you've shown,
you could also macrodef them if they really are that similar for all
databases.
The whole check-then-test logic could be streamlined into a single
macro with Ant-Contrib's if if you feel that inclined. A pure Ant
solution would probably look like:
* write a build file that contains check and test targets much like
your old build file did and use properties for all DB specific things
(JDBC driver, property file). No macros, plain old targets.
* for each database you intend to support write a tiny little build
file that imports the build file above and sets the properties.
If you ever encounter a database that needs more complicated checks
than the ones you have so far, you can override the check target
(import supports target inheritance).
* In you master build file, subant over your database specific build
files.
But we are really getting off Gump-topic here 8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Existence of a database?
I was talking ant 1.4 indeed :) Mvgr, Martin On Mon, 2004-05-24 at 09:18, Stefan Bodewig wrote: On Wed, 19 May 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: Use antcall to call the target with the db specific properties, this way you can merge the postresql and the mysql targets. No. Use Ant 1.6+ and macrodef. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Existence of a database?
On Sat, 15 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote: Could we assume that gump machines have a database that these test cases can connect to? You can savely assume that hsqldb is around[1] but not installed in any way. I.e. you could make your tests depend on hsqldb and they'd work in Gump. Even if some Gump machine may use some kind of DB in the future (to gather historical data or whatever else we come up with), there'll be no guarantee that all machines have one. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Existence of a database?
I find that depending on an external database makes the unit tests very brittle.. Unless you are specifically testing something that requires a specific type of database, I find that using hsqldb or axion works fine.. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Existence of a database? On Sat, 15 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote: Could we assume that gump machines have a database that these test cases can connect to? You can savely assume that hsqldb is around[1] but not installed in any way. I.e. you could make your tests depend on hsqldb and they'd work in Gump. Even if some Gump machine may use some kind of DB in the future (to gather historical data or whatever else we come up with), there'll be no guarantee that all machines have one. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Existence of a database?
Thanks everyone for answering. At 01:27 PM 5/19/2004, Eric Pugh wrote: I find that depending on an external database makes the unit tests very brittle.. Unless you are specifically testing something that requires a specific type of database, I find that using hsqldb or axion works fine.. I agree that having tests run all several databases makes things complicated and brittle. We currently have tests unit tests that work on mysql and postgres. The Junit test case plus the related log4j config files import a DB specific property file at runtime if it is available on the local system, otherwise the test for that db are skipped. Adding tests for other databases should be easy, except that it would result in duplication of targets in the Ant build file. The build file is available here: http://cvs.apache.org/viewcvs.cgi/logging-log4j/tests/build.xml?rev=1.54 The relevant part is reproduced below. !-- = -- !-- = DB Tests === -- !-- = -- !-- These tests follow the same pattern. They will be run if a property file defining access as well as necessary class files are available. Otherwise, the test is skipped. -- target name=mysqlCheck condition property=mysql-present and available file=./input/db/mysql.properties / available classname=com.mysql.jdbc.Driver classpath refid=tests.classpath/ /available /and /condition /target target name=mysql depends=mysqlCheck, build if=mysql-present delete file=./input/db/db.properties/ echo message=MySQL available/ copy file=./input/db/mysql.properties tofile=./input/db/db.properties/ junit printsummary=yes fork=no haltonfailure=yes sysproperty key=runLen value=100/ classpath refid=tests.classpath/ formatter type=plain usefile=false/ test name=org.apache.log4j.db.FullCycleDBTest / /junit /target target name=postgresqlCheck condition property=postgresql-present and available file=./input/db/postgresql.properties / available classname=org.postgresql.Driver classpath refid=tests.classpath/ /available /and /condition /target target name=postgresql depends=postgresqlCheck, build if=postgresql-present delete file=./input/db/db.properties/ echo message=PostgreSQL available/ copy file=./input/db/postgresql.properties tofile=./input/db/db.properties/ junit printsummary=yes fork=no haltonfailure=yes sysproperty key=runLen value=100/ classpath refid=tests.classpath/ formatter type=plain usefile=false/ test name=org.apache.log4j.db.FullCycleDBTest / /junit /target As you can see there is almost complete duplication of the tasks for mysql and postgresql. I wonder if it possible to group tasks and invoke them as a function or a method call. Anyway, I am digressing. Thanks for your help. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Existence of a database? On Sat, 15 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote: Could we assume that gump machines have a database that these test cases can connect to? You can savely assume that hsqldb is around[1] but not installed in any way. I.e. you could make your tests depend on hsqldb and they'd work in Gump. Even if some Gump machine may use some kind of DB in the future (to gather historical data or whatever else we come up with), there'll be no guarantee that all machines have one. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Existence of a database?
Use antcall to call the target with the db specific properties, this way you can merge the postresql and the mysql targets. You can eg add a commandline parameter for the people who eg just want to run the postgressql target eg ant -Ddbtest=mysql. Mvgr, Martin On Wed, 2004-05-19 at 14:01, Ceki Gülcü wrote: Thanks everyone for answering. At 01:27 PM 5/19/2004, Eric Pugh wrote: I find that depending on an external database makes the unit tests very brittle.. Unless you are specifically testing something that requires a specific type of database, I find that using hsqldb or axion works fine.. I agree that having tests run all several databases makes things complicated and brittle. We currently have tests unit tests that work on mysql and postgres. The Junit test case plus the related log4j config files import a DB specific property file at runtime if it is available on the local system, otherwise the test for that db are skipped. Adding tests for other databases should be easy, except that it would result in duplication of targets in the Ant build file. The build file is available here: http://cvs.apache.org/viewcvs.cgi/logging-log4j/tests/build.xml?rev=1.54 The relevant part is reproduced below. !-- = -- !-- = DB Tests === -- !-- = -- !-- These tests follow the same pattern. They will be run if a property file defining access as well as necessary class files are available. Otherwise, the test is skipped. -- target name=mysqlCheck condition property=mysql-present and available file=./input/db/mysql.properties / available classname=com.mysql.jdbc.Driver classpath refid=tests.classpath/ /available /and /condition /target target name=mysql depends=mysqlCheck, build if=mysql-present delete file=./input/db/db.properties/ echo message=MySQL available/ copy file=./input/db/mysql.properties tofile=./input/db/db.properties/ junit printsummary=yes fork=no haltonfailure=yes sysproperty key=runLen value=100/ classpath refid=tests.classpath/ formatter type=plain usefile=false/ test name=org.apache.log4j.db.FullCycleDBTest / /junit /target target name=postgresqlCheck condition property=postgresql-present and available file=./input/db/postgresql.properties / available classname=org.postgresql.Driver classpath refid=tests.classpath/ /available /and /condition /target target name=postgresql depends=postgresqlCheck, build if=postgresql-present delete file=./input/db/db.properties/ echo message=PostgreSQL available/ copy file=./input/db/postgresql.properties tofile=./input/db/db.properties/ junit printsummary=yes fork=no haltonfailure=yes sysproperty key=runLen value=100/ classpath refid=tests.classpath/ formatter type=plain usefile=false/ test name=org.apache.log4j.db.FullCycleDBTest / /junit /target As you can see there is almost complete duplication of the tasks for mysql and postgresql. I wonder if it possible to group tasks and invoke them as a function or a method call. Anyway, I am digressing. Thanks for your help. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Existence of a database? On Sat, 15 May 2004, Ceki Gülc [EMAIL PROTECTED] wrote: Could we assume that gump machines have a database that these test cases can connect to? You can savely assume that hsqldb is around[1] but not installed in any way. I.e. you could make your tests depend on hsqldb and they'd work in Gump. Even if some Gump machine may use some kind of DB in the future (to gather historical data or whatever else we come up with), there'll be no guarantee that all machines have one. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/hsqldb/hsqldb/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
