ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Stevens <>
Subject Re: Command-Line execution of a third-party task
Date Fri, 23 Mar 2012 13:28:51 GMT
Hi Dominique,

The way I read his original message, Mike just wants to run sonar
against a project with an existing build.xml and was asking about
direct use from the command line only because he isn't able/allowed to
change the build.xml. But I wasn't sure if that applied to just
build.xml or was a more general restriction...

Given the hoops you might have jump through on the command line to
pass in the parameters, I figured it was worth pointing out that Ant
scripts don't *have* to be called "build.xml", and a supplementary
build script (which could even be created on the fly in a shell
script) that can import the first and inherit its existing properties
and init stuff might be much simpler than any workaround/hack to
execute the task directly.  Especially if you have to read some values
from a properties file, perform variable substitution to calculate
others, build paths from a fileset, ...

Besides, if using *only* the command line directly was so essential,
why bother messing around with the ant task anyway when sonar itself
has a command line runner?  The only advantage to the Ant task is that
it's, well, an Ant task.  Run it from an Ant script, the way it's
chiefly designed to be run ;-)

Just my opinion, anyway.


On 23 Mar 2012 10:44, "Dominique Devienne" <> wrote:
> On Fri, Mar 23, 2012 at 9:29 AM, Andy Stevens
> <> wrote:
> > Why not just create your own mybuild.xml and run that with ant -f ?
> > No need to alter the original build.xml, but you could always import it to
> > take advantage of any initialise targets etc.
> Note that Mike mentioned executing *tasks* from the CLI, not targets,
> i.e. potentially without any build.xml.
> For example "ant -e mkdir -dir=foo" or "ant -e zip
> '-includes=classes/**' -destfile=classes.jar".
> He does mention having many build files, and using *custom* tasks,
> which might require explicit taskdefs and classpaths, but assuming the
> custom tasks are already packaged in an antlib that's already on the
> classpath, or explicitly loaded with -lib, then it's only the matter
> of prefixing the task name with its namespace, as in "ant -lib
> libs/ant-contrib.jar -e antlib:net.sf.antcontrib:sometask ...".
> But maybe I didn't quite understand Mike's original post. In any case,
> I kinda like his idea, or Maven's I guess, the way I understood it at
> least :) --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message