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. Andy. On 23 Mar 2012 10:44, "Dominique Devienne" <ddevie...@gmail.com> wrote: > > On Fri, Mar 23, 2012 at 9:29 AM, Andy Stevens > <insomniacpeng...@googlemail.com> 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: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org
