ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Longman <>
Subject Re: global properties
Date Thu, 20 Sep 2001 20:44:41 GMT
On Thu, 2001-09-20 at 13:37, Diane Holt wrote:
> --- Craig Longman <> wrote:
> > both are being set just to see if it fails.  under normal conditions, i
> > would only set one of them, having more than one set would be cause for
> > an error.
> Under normal conditions, how would one of either use.target1 or
> use.target2 get set? -- command-line define? -- property file? -- set
> within a target in the build-file?

i'm not sure yet.  i had initially just left a target at the top of the
build.xml file that could be modified as the need arose.  but i think it
will probably be converted to a properties file to simplify it.

> > prop1 is just a flag to determine whether the targets have been
> > executed.  it was just a way of having something check if it was already
> > set and if so, assume that the initialization has already been
> > completed.  prop2 just represents a property that i am actually
> > interested in have ONE of the two targets configure.
> I'm not sure what initialization you're doing but, because of the
> immutability of properties, if you set prop2 in both target1 and target2,
> whichever target ran first will be who determined what prop2 will be set
> to, so if all target1 and target2 do is set a particular property, it
> won't matter if both run -- only which is run first (assuming you're no
> longer running target1 and target2 via <antcall>'s).

ok, here is a bit of an explanation:

i'm writing a build file to allow for easy deployment of our html for
our project.  part of the html is a property containing the URL for JDBC
to use to connect to the database.  we need to be able to handle
multiple databases, each of which use different urls to connect.  so,
the basic idea is, the deployer would set the database type (db2/pgsql
for eg) and provide the host,port,db,uid,pwd for the connection.  then,
the build.xml file would figure out the rest, using the preferred
Driver, build the URL, etc.  then use this to replace tokens in the
files that are being deployed.

so, assuming these properties:

then the build.xml:

<target name="default" depends="init">

<target name="init">
 < in props...>
 <antcall target="db-db2">
 <antcall target="db-pgsql">

<target name="db-db2" if="db.type.db2" depends="check-db-config">
 <property name="db.config" value="true"/>
 <property name="db.url" value="jdbc:db2:${}:${db.port}/${}"/>
 <property name="db.driver" value=""/>

<target name="db-pgsql" if="db.type.pgsql" depends="check-db-config">
 <property name="db.config" value="true"/>
 <property name="db.url" value="jdbc:postgresql://${}:${db.port}/${}"/>
 <property name="db.driver" value="org.postgresql.Driver"/>

<target name="check-db-config" if="db.config">
 <fail message="only one db.type property please"/>

so, there's the basic problem.  the fact that 'antcall' tag handles
properties in a completely different fashion to the 'depends' attribute
means that this won't work.  invoking the db-XXX targets  in the
'depends' attribute of the init tag won't work, as other things get
initialized in that target.  and invoking the db-XXX targets from the
depends in the default target is also undesireable for the folowing
  - there is no guaranteed order of execution in the depends list (at
least, its not guaranteed to execute in the order provided)
  - there will be multiple targets like 'default', managing all of them
is painful
  - finally, if they're called from any 'depends' attribute, then the
fact that the check-db-config target will only get called once pretty
much negates the whole point of it.

i guess i just must be doing things that ant isn't really designed to
do.  it seemed like it would be a good tool for it, but this has really
proved to be painful and i'm not exactly sure why.   other than to think
that configuring complicated parameters to setup properties files in a
large install is not the point of it, but i'm not sure thats true
either.  anyway, i like some of the other things about ant, so i will
probably just remove the error/sanity checking and accept the 'hack' of
just using the depends to invoke the db-XXX targets for now.  and then
maybe work on some of the other possibilities i've mentioned in the
'suggestions' thread.



View raw message