You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Cyril Sagan <cy...@unx.sas.com> on 2005/12/06 00:34:59 UTC

Mystery failures with [prj name].[target] in depends list.

SUMMARY:
Using the "full" syntax, [project's name attribute].[target], to
reference targets causes builds to fail unless that target exists in
more than one build file!  Can anyone explain why this is the case?


BACKGROUND:
I've begun using Ant 1.6-based constructs to break up large build
files, I may have found a bug, certainly the behavior is a mystery to
me.  I've googled and searched bugzilla with no success, I'd like to
hear from the experts before reporting this as a bug.

  [ Aside: What's the right terminology for the 1.6 target names
    which are prefixed with their project name's?  The "fully
    qualified" concept, like a file path, comes to mind.  Does it
    make sense in the Ant target name context?  Knowing the correct
    term would have made my searches more useful. ]

Consider this example:

    helper.xml
    ----------
    <?xml version="1.0"?>
    <project name="helper">
        <target name="init">
            <echo message="1. helper init"/>
        </target>
    </project>


    build.xml
    -----------
    <?xml version="1.0"?>
    <project name="main" default="go">
        <import file="helper.xml" />

        <target name="init" depends="helper.init">
           <echo message="2. main init"/>
        </target>

        <target name="go" depends="init">
            <echo message="3. Run build!" />
        </target>
    </project>

Here I show how this works as expected:
    $ ant -version
    Apache Ant version 1.6.5 compiled on June 2 2005

    $ ant
    Buildfile: build.xml

    helper.init:
         [echo] 1. helper runs init

    init:
         [echo] 2. main init

    go:
         [echo] 3. Run build!

    BUILD SUCCESSFUL
    Total time: 0 seconds
    

BUT, if I give the init target a different name, IN EITHER FILE, and
continue to use the helper.[target] syntax for naming targets in the
depends attribute, the build fails!!  That is, if I change build.xml
to:
    <?xml version="1.0"?>
    <project name="main" default="go">
        <import file="helper.xml" />
    
        <target name="main-init" depends="helper.init">
           <echo message="2. main init"/>
        </target>
    
        <target name="go" depends="main-init">
            <echo message="3. Run build!" />
        </target>
    </project>    

...then this failure results:
    $ ant
    Buildfile: build.xml

    BUILD FAILED
    Target `helper.init' does not exist in this project. It is used from target `main-init'.

    Total time: 0 seconds


Seems that the target named "helper.init" only works there is another
init target somewhere.  Even a dummy/unused target is enough to make
the failure go away.  Adding:
    <target name="init" />  <!-- dummy -->

...anywhere in the main build.xml makes the above error go away. 

This issue surfaced because I'd like to structure our build files so a
"global.init" target is always depended upon regardless of whether a
project has added their own local "init" target.

I conclude that you can only use the "fully qualified" target naming
scheme to when distinguishing ambiguity is required.  Does anyone else
think this is a bug?   Thanks in advance.

--Cyril

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Mystery failures with [prj name].[target] in depends list.

Posted by Dominique Devienne <dd...@gmail.com>.
> I conclude that you can only use the "fully qualified" target naming
> scheme to when distinguishing ambiguity is required.  Does anyone else
> think this is a bug?   Thanks in advance.

Right. You can only use <imported>.target when the importer
'overrides' the target in question. Others have complained about it,
and the HEAD now always exposes the imported targets using the
<imported>.target syntax, whether overriden or not.

You'll have to wait for Ant 1.7 though, or compile your own from SVN's
trunk. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org