0

I have run into a problem regarding the build script. Presently I have a main build.xml file that calls each internal build.xml files from a directory. The internal build.xml has 2 stages to execute wherein at the end i get a jar file. My requirement is that if anything foes wrong in the 1st step of the internal build.xml file, i should not get the jar file, but the main build should continue execution and go to the next internal build.xml file. In the internal build.xml based on some condition i want to stop that internal build.What changes should i make in my code to stop that particular build? Thanks in advance.

fge
  • 119,121
  • 33
  • 254
  • 329
user1947679
  • 49
  • 2

2 Answers2

5

Set failonerror="false" on your subant tasks you're using to call the other build files.

thekbb
  • 7,668
  • 1
  • 36
  • 61
  • editorial comment: I don't recommend doing this... you want to know when a build fails. This hack takes away all your visibility. If you want to have some projects built if one fails - split them up into multiple builds (or don't call them from a common build file). – thekbb Aug 01 '13 at 16:17
0

If you can afford to add ant-contrib to your build, then it is easy. In your main task, do:

<target name="xxx">
    <var name="firstStepOK" value="true"/>
    <trycatch>
        <try>
            <!-- call first sub build -->
        </try>
        <catch>
            <var name="firstStepOK" value="false"/>
        </catch>
    </trycatch>
    <!-- call second sub build, pass value of firstStepOK -->
</target>

Unfortunately, ant-contrib has never made it into ant proper, which is a pity. It contains very useful tasks.

fge
  • 119,121
  • 33
  • 254
  • 329
  • 6
    Ant is kinda goofy - in hindsight xml was a poor decision for ant. Ant wasn't meant to be a scripting language, but rather a list of declarations, with any heavy lifting done with a task (written in java). Ant-contrib doesn't solve ant's goofiness as much as makes them worse. ant-contrib usually leads to build files with poor maintainability. let ant be ant, don't try to make it a scripting language - it will always suck at that (arguably it sucks as a build definition language too) – thekbb Jul 31 '13 at 20:23
  • @thekbb I disagree. ant-contrib is the _only_ way to inject some sense into ant itself (for instance, `var` -- I will always fail to understand the reasoning behind making properties immutable). And I don't understand that -1. My solution Just Works(tm). Since then anyway, I have switched to gradle. – fge Aug 01 '13 at 18:13
  • 1
    We're way more in agreement than we're in disagreement. It's hard because I think we both wanted to say "don't use ant", but that doesn't help OP. My answer should have been more like this old one": http://stackoverflow.com/a/6301879/505191 (the links are decent). I downvoted because I honestly believe it's not a good idea, and wanted to signal that to the OP and more importantly the many people that will find this question (who I may end up working with in the future). I meant no personal offense. I really like this site and believe it works better when we vote more (particularly downvotes) – thekbb Aug 02 '13 at 16:28