ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Rohead" <sean.roh...@nextpage.com>
Subject Re: Bug 3304
Date Thu, 25 Sep 2003 16:36:14 GMT
Thanks for the replies.
 
Unfortunately, the suggested workarounds aren't really ideal either.  I don't want the <ant>
task to use the current (containing) target, I want the ant task to use the target that was
provided on the command line - otherwise I still have to put <ant> tasks in every top-level
target.  For instance, I have compile, test, dist, etc... as top-level targets, but I really
only want to put the <ant> task in the lib target which is a prerequisite of all of
the above.
 
But I'm still confused about the reluctance to embrace the original proposal.  Is there some
fundamental design principle that would be violated by setting a standard ant.target property
which contained the target(s) specified by the user on the command line and could then be
passed on to the <ant> task?  This also avoids the messiness described below about breaking
property immutability.
 
Thanks,
 
Sean Rohead
 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 
Workaround:
 
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="test" basedir="." default="main">
 
    <target name="main">
        <script language="javascript"> <![CDATA[
            name = self.getOwningTarget().getName();
            project.setProperty("target.name",name);
        ]]></script>
        <echo>target.name=${target.name}</echo>
        <antcall target="script"/>
    </target>
 
    <target name="script">
        <script language="javascript"> <![CDATA[
            name = self.getOwningTarget().getName();
            project.setProperty("target.name",name);
        ]]></script>
        <echo>target.name=${target.name}</echo>
    </target>
 
</project>
 
 
But it´s not the fine way to overwrite the property ...
 
I think it is no problem to implement. But then we will brake to golden
rule "properties are immutable" (see example).
If you have to specify the property in which the target name should be
stored,
you can code that in a normal <property/>. (... I got an idea ...)
If you want to have a "global" property (like ant.project.name) the value
has
to overwritten in each target (otherwise it wouldn´t be really useful).
 
 
Back to my idea:
A task which gets the current target name and tries to store it into a 
property. Maybe it should fail if that property is already set (to a
different
value).
 
<target name="helloWorld">
    <getTargetName property="tname"/>
    <echo>${tname}</echo>
</target>
 
would print "helloWorld"
 
<getTargetName property="tname" fail="never|differ|isset"/>
control the behaviour if the property tname is already set
- never:   don´t throw a BuildException (log in verbose); don´t set the
property
           --> "properties are immutable"
- differ:  throw a BE if the value differs from the current target name;
           don´t set the property (useless, has the "right" value :-)
- isset:   throw a BE if the property is set; set the property
 
 
Would that help?
 
 
 
Jan

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message