ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Bergeron" <jacques.berge...@dogico.com>
Subject RE: Environment variables for exec [EXPIRED TRIAL LICENCE]
Date Sat, 17 Jun 2000 08:41:05 GMT
Bonjour Hulien, Hi all!

I dont't think anybody responded to your questions so I will try to give you
some tips.

I just started using Ant this week so if I'm saying stupid things could the
other participants point them out.

> Specifying environment variables for an Exec task would be nice, but I
don't
> see how the variables/values could be passed in a platform independant
way.
> The build.sh / build.bat solution that is sourced before the exec is not
> very nice. Did somebody think of a better way ?

You may use a generic subproject for your commands. The "main" project can
do the equivalent of a .sh/.bat in an environment independant way. I use
environment because most of the time the diffences should occur more because
of configuration then the OS. You can use the ANT predifined task to call
the subproject.

> I also have the following problem : I want to repeat the same task
(copying
> files, zipping, comparing, ...) with a different parameter each time. I
> don't want to have a custom task that does the whole loop, since most of
the
> work that is done in one loop could be done by existing task (zip,
copydir,
> ...).
> Is there a reason a looping mechanism could not be included in Ant ?

Interesting, based on the preceding point you could have a "main" project
that would look something like:

<project name=main...
  <target name="looping" depends="init">
    <property name="var-prop" value="value1"/>
    <ant antfile="subbuild.xml" dir="$(var-prop)"/>
    <property name="var-prop" value="value2"/>
    <ant antfile="subbuild.xml" dir="$(var-prop)"/>
  </target>
</project>

Any var-prop property in subbuild.xml will be overriden by the "main"
project values for var-prop.

You could even GENERATE the main project build file using XSLT (try Xalan to
stay in the Apache family!) so you could start with an XML file like.

<builds>
  <build id=1>
    <var-prop-1>value1-1</var-prop-1>
    ...
  </build>
  <build id=2>
  ...
</builds>

The call to Xalan could pretty well be embedded itself as a task in Ant.

etc.

> Also, wouldn't it be nice to be able to specify <target ifnot="A"> instead
> of <target if="">, where the task is only executed if "A" is not set, and
> returns fine all the time.

I think <target if="notA"/> does the same. You define "A" or you define
"notA".

> It is in the same idea than a <try > rather than <target >.
> And in general way, it would be nice if a target could fail if something
is
not done (and that can't be done by another target).

Agreed, testing return codes (or something like that) would be VERY nice and
coherent with that kind of tool.

> I don't know if what I write is clear, but I do my best.

No worst then me!!!


A la prochaine,

Jacques


Mime
View raw message