groovy

CLONE -Using the Ant task with multiple targets fails

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.5, 1.5.8, 1.6.4, 1.7-beta-1
  • Fix Version/s: 1.7-beta-2, 1.6.6
  • Component/s: Ant integration
  • Labels:
    None
  • Environment:
    Windows and Linux
    Java 1.5
    Ant 1.6.5
  • Number of attachments :
    2

Description

From the mailing list wrap-up post by Dierk:

<quote>
def ant = new AntBuilder()
ant.ant(antfile:'build.xml'){
target(name:'one')
}

is working but

def ant = new AntBuilder()
ant.ant(antfile:'build.xml'){
target(name:'one')
target(name:'two')
}

is not. The flag 'targetAttributeSet' is set erroneously in org.apache.tools.ant.taskdefs.Ant#addConfiguredTarget.
(possible Ant bug?)
</quote>

(Having looked at the Ant source myself, I can only see targetAttributeSet being set in setTarget, so personally I suspect it's not an Ant bug.)

To find the mailing list thread, search for a subject of "AntBuilder.ant.target not working?" on Feb 23rd/24th 2006. (Web access to mailing list is down right now, hence the lack of URL.)

  1. groovy3763C.patch
    19/Sep/09 10:57 AM
    4 kB
    Paul King
  2. groovyant.tar.gz
    18/Sep/09 5:08 PM
    0.4 kB
    Binil Thomas

Issue Links

Activity

Hide
Binil Thomas added a comment -

def ant = new AntBuilder()
ant.ant(antfile: 'build.xml') {
target(name: 'one')
}

<project name="testprj" default="three">
<target name="one">
<echo message="Target ONE"/>
</target>
<target name="two">
<echo message="Target TWO"/>
</target>
<target name="three">
<echo message="Target DEFAULT"/>
</target>
</project>

groovyant/test.groovy
groovyant$ ant -version
Apache Ant version 1.7.1 compiled on July 16 2009
groovyant$ groovy -version
Groovy Version: 1.6.3 JVM: 1.6.0_15
groovyant$ groovy test.groovy

three:
[echo] Target DEFAULT
groovyant$

Show
Binil Thomas added a comment - def ant = new AntBuilder() ant.ant(antfile: 'build.xml') { target(name: 'one') } – <project name="testprj" default="three"> <target name="one"> <echo message="Target ONE"/> </target> <target name="two"> <echo message="Target TWO"/> </target> <target name="three"> <echo message="Target DEFAULT"/> </target> </project> – groovyant/test.groovy groovyant$ ant -version Apache Ant version 1.7.1 compiled on July 16 2009 groovyant$ groovy -version Groovy Version: 1.6.3 JVM: 1.6.0_15 groovyant$ groovy test.groovy three: [echo] Target DEFAULT groovyant$
Hide
Paul King added a comment -

Possible regression in GROOVY-1260?

Show
Paul King added a comment - Possible regression in GROOVY-1260?
Hide
Paul King added a comment -

Seems to work in 1.5.4 but not in 1.5.5.
My guess is it is related to GROOVY-2692, perhaps this change:
http://fisheye.codehaus.org/viewrep/groovy/trunk/groovy/groovy-core/src/main/groovy/util/AntBuilder.java?r1=10326&r2=11124
Though there are also some other Ant/Builder related issues in that release: GROOVY-2591 GROOVY-2424 GROOVY-2643

Show
Paul King added a comment - Seems to work in 1.5.4 but not in 1.5.5. My guess is it is related to GROOVY-2692, perhaps this change: http://fisheye.codehaus.org/viewrep/groovy/trunk/groovy/groovy-core/src/main/groovy/util/AntBuilder.java?r1=10326&r2=11124 Though there are also some other Ant/Builder related issues in that release: GROOVY-2591 GROOVY-2424 GROOVY-2643
Hide
Paul King added a comment - - edited

So it seems that 'target' has now been taken over for defining targets but perhaps that isn't what we want inside the 'Ant' task.
The workaround for a single target (so the regression is over and above the multiple target case) is to use the target attribute instead of the nested version.
A possible workaround for multiple targets if you have access to the build file and can modify it, is to make a special target which depends on those you require.

Show
Paul King added a comment - - edited So it seems that 'target' has now been taken over for defining targets but perhaps that isn't what we want inside the 'Ant' task. The workaround for a single target (so the regression is over and above the multiple target case) is to use the target attribute instead of the nested version. A possible workaround for multiple targets if you have access to the build file and can modify it, is to make a special target which depends on those you require.
Hide
Paul King added a comment -

The attached patch gets around the issue unless someone can think of a more elegant solution. I also haven't checked whether other tasks also have nested target entries. I wonder if it would not be better to flip it around to do the special 'target definition' handling only at the top level.

Show
Paul King added a comment - The attached patch gets around the issue unless someone can think of a more elegant solution. I also haven't checked whether other tasks also have nested target entries. I wonder if it would not be better to flip it around to do the special 'target definition' handling only at the top level.
Hide
Paul King added a comment - - edited

'B' patch is a little more elegant in that it only allows ant.target to define a new target when not inside any task. So, the following example now works (as a script but strangely not pre-compiled) whereas previously the 'two' target wouldn't have been called as it would have been regarded as target definition.

ant.import(file: 'build.xml')
ant.antcall(target:'one')
ant.antcall { target(name:'two') }
Show
Paul King added a comment - - edited 'B' patch is a little more elegant in that it only allows ant.target to define a new target when not inside any task. So, the following example now works (as a script but strangely not pre-compiled) whereas previously the 'two' target wouldn't have been called as it would have been regarded as target definition.
ant.import(file: 'build.xml')
ant.antcall(target:'one')
ant.antcall { target(name:'two') }
Hide
Paul King added a comment -

Turned out the 'B' patch with antcall was only working because the imported build.xml file happened to be in the current directory. So instead the 'C' patch prohibits calling antcall at top level. The only other alternative I can think of is to keep track of imported files and associate them with their corresponding targets. We could set the "ant.file" system property prior to calling perform on the antcall task. It would be a bit of work ensuring properties were set correctly. And it would seem a little strange that you then couldn't use antcall for a manually created target.

Show
Paul King added a comment - Turned out the 'B' patch with antcall was only working because the imported build.xml file happened to be in the current directory. So instead the 'C' patch prohibits calling antcall at top level. The only other alternative I can think of is to keep track of imported files and associate them with their corresponding targets. We could set the "ant.file" system property prior to calling perform on the antcall task. It would be a bit of work ensuring properties were set correctly. And it would seem a little strange that you then couldn't use antcall for a manually created target.
Hide
Paul King added a comment -

I believe patch C is the correct current solution to this issue unless further feedback is received. I won't be in a position to apply for the next two weeks, so if a release goes out before then, it would be great if someone else can apply the patch.

Show
Paul King added a comment - I believe patch C is the correct current solution to this issue unless further feedback is received. I won't be in a position to apply for the next two weeks, so if a release goes out before then, it would be great if someone else can apply the patch.
Hide
Paul King added a comment -

Patch C applied to trunk and 1.6.X

Show
Paul King added a comment - Patch C applied to trunk and 1.6.X

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: