ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <dic...@nortelnetworks.com>
Subject RE: Unadorned output (i.e. ant -emacs)
Date Fri, 08 Jun 2001 12:53:10 GMT


> -----Original Message-----
> From: Daniel Rall [mailto:dlr@finemaltcoding.com]
> You're right that the Record class doesn't seem entirely appropriate
> for the effect I'm trying to achieve.  I want to modify the output of
> the configured BuildLogger write to stdout, just like `ant -emacs`
> does in the Main class (as opposed to filtering the output and writing
> to a file).  Controlling settings on the logger via a property is the
> best way I can come up to achieve this (there is a precendent with a
> property like java.compiler).
> 
> I'm not really sure what to do at this point, and could use some
> direction.  If there is something that I can clarify in the
> explanation of my situation, please ask.  I am very willing to write
> code to put this feature in place.
> 
> Thanks,
> Daniel
> 

I don't think that specifying it in the build file itself is very useful.
The reason for this is due to the need for this property to apply to the
full execution of Ant.  I.e.: the -emacs affects all output of ant, starting
even before the build.xml file has been read.  If you place this in the
build file (a sequential object), then the setting implies that it's from
that point on.  Either that, or you're going to have to teach ant to
pre-parse the xml file for this property, before it tries to go through and
create the tasks.

The problems above also apply to a properties file, as they are usually read
by a command in the xml file.  However, there is an alternative: you could
introduce a new properties file that contains properties that affect the
behaviour of ant (as opposed to the actions of ant - like tasks).

If you don't want to create wrapper scripts for ant, one workaround could be
to create a wrapper xml file.  For example, if your current xml file is
build.xml, then rename it to main.xml and create a new build.xml file that
calls mail.xml, either through the <ant> task or through the <exec> task.
For example, build.xml could look like this:
<project name="wrapper_build" basedir="." default="go" >
	<property file="./default.properties" />
	<property name="use_emacs" value="" />
	<target name="go">
		<exec executable="ant">
			<arg value="${use_emacs}" />
		</exec>
	</target>
</project>
Where use_emacs is over-ridden in default.properties or the command line to
be "-emacs".  Why is this better then a wrapper script?  It's platform
independent.  Is this workaround (and I cannot stress that this is just that
- a workaround) better then some of the suggestions above, where you need to
modify the behaviour of ant?  No.

Sorry for this non-answer, but I hope it helps to clarify things.

JDG

Mime
View raw message