I have a requirement where I have to run a while loop in ant script.
I have to check for the status of a file (it is being created by some other process) in the while loop and perform some task based on it.
I strongly urge you not to use third party tasks that provide looping capability if at all possible. Introducing programming logic such as loops and if statements can easily make your build scripts into unusable spaghetti code.
For your specific case, native Ant already has a much simpler solution. You can use the waitfor task with a nested available condition pointed to the file in question:
<waitfor>
<available file="/path/to/your/file" />
</waitfor>
https://ant.apache.org/manual/Tasks/waitfor.html
https://ant.apache.org/manual/Tasks/available.html
Related
i have this ant build.xml file with 3 targets in it:
target1, target2 and target3.
If the user simply runs ant and not an explicit ant target1 or something like that, i want to prompt the user asking which target he would like to call.
Remember, the user should only be prompted for this only if he doesnt explicitly call a target while running ant
Ant is not a programming language, it's a dependency matrix language. There's a big difference between the two.
In a program language, you can specify the absolute order of sequence. Plus, you have a lot more flexibility in doing things. In Ant, you don't specify the execution order. You specify various short how to build this steps and then specify their dependencies. Ant automatically will figure out the execution order needed.
It's one of the hardest things for developers to learn about Ant. I've seen too many times when developers try to force execution order and end up executing the same set of targets dozens of times over and over. I recently had a build her that took almost 10 minutes to build, and I rewrote the build.xml to produce the same build in under 2 minutes.
You could use <input/> to get the user input, then use <exec> or <java> to execute another Ant process to execute the requested target. However, this breaks the way Ant is suppose to work.
The default target should be the default target that developers would want to execute on a regular basis while they program. It should not clean the build. It should not run 10 minutes of testing. It should compile any changed files, and rebuild the war or jar. That's what I want about 99% of the time. The whole process takes 10 seconds.
I get really, really pissed when someone doesn't understand this. I hate it when I type ant and I get directions on how to execute my build. I get really irritated when the default target cleans out my previous compiles. And, I get filled with the deadly desire to pummel the person who wrote the damn build file with a large blunt object if I am prompted for something. That's because I will run Ant, do something else while the build happens, then come back to that command window when I think the build is done. Nothing makes me angrier to come back to a build only to find out it's sitting there waiting for me to tell it which target.
If you really, really need to do this. Use a shell script called build.sh. Don't futz with the build.xmlto do this because that affects development.
What you really need to do is teach everyone how to use Ant:
Ant will list user executable targets when you type in ant -p. This will list all targets, and their descriptions. If a target doesn't have a description, it won't list it. This is great for internal targets that a user shouldn't execute on their own. (For example, a target that merely does some sort of test to see if another target should execute). To make this work, make sure your targets have descriptions. I get angry when the person who wrote the Ant file puts a description for some minor target that I don't want, but forgets the description of the target I do want (like compile). Don't make David angry. You don't want to make David angry.
Use default target names for your group. That way, I know what targets do what across the entire project instead of one project using BUILD vs. build-programs vs. Compile vs build-my-stuff vs. StuffBuild. We standardized on Maven lifecycle names names. They're documented and there's no arguments or debates.
Do not use <ant/> or <antcall> to enforce build order. Do not divide your build.xml into a dozen separate build.xml programs. All of these probably break Ant's ability to build a target dependency matrix. Besides, many Ant tools that show dependency hierarchy in a build and they can't work across multiple build files.
Do not wrap your builds inside a shell script. If you do this, you're probably not understanding how builds work.
The build should not update any files in my working directory that were checked out by me. It shouldn't polute my working directory with all sorts of build artifacts spread out all over the place. It shouldn't do anything outside of the working directory (except maybe do some sort of deploy, but only when I run the deploy target). In fact, all build processing should take place in a sub-directory INSIDE my working directory. A clean should merely delete this one directory. Sometimes, this is called build, sometimes dist. I usually call it target because I've adopted Maven naming conventions.
Your build script should be a build script. It shouldn't do checkouts or updates -- at least not automatically. I know that if you use CruiseControl as a continuous build process, you have to have update and checkout functionality inside your build.xml. It's one of the reasons I now use Jenkins.
Sorry about this answer not necessarily being the one you're looking for. You didn't really state what you're doing with Ant. If you're doing builds, don't do what you're trying to do. If you're writing some sort of program, use a real programming language and not Ant.
An Ant build should typically finish in under a minute or two, and redoing a build because you changed a file shouldn't take more than 30 seconds. This is important to understand because I want to encourage my developers to build with Ant, and to use the same targets that my Jenkins server uses. That way, they can test out their build the same way my Jenkins server will do the official build.
you may use the input task provided by ant and make it your default target.
<input
message="Please enter Target ID (1,2 or 3):"
validargs="1,2,3"
addproperty="targetID"
/>
Use the value of this property to decide which target to execute.
From the ant documentation:
message : The Message which gets displayed to the user during the build run.
validargs: Comma separated String containing valid input arguments. If set, input task will reject any input not defined here.
You may pass any arguments according to your needs.
addproperty : The name of a property to be created from input.Behaviour is equal to property task which means that existing
properties cannot be overridden.
Ant has a nifty element but when used results in confusing messages. The output from Ant seems to consist of just the union of both sets of messages. Is there any way to separate these out or, at least, force Ant to serialize them as if they were run sequentially?
I do not believe so, Ant is doing a FIFO. I would advise printing the thread ID along with message to help make sense of the messages.
I have a build file that has different variety of tasks. Some of these are in-house tasks that I am able to control the amount of logging/output generated.
The other tasks are libraries that I have no control over. They do not provide a way to control the amount of output. There is one very trivial task and I am comfortable with turning off the output of the task all together.
My question is if there a way to turn off this specific tasks output in the ant execution. Or does ant provide a way to wrap this task in another task that has echo set to 'off' or something similar?
-Syam
Ant has no builtin feature to turn off output for specific task, but there are possibilities via buildlisteners. See Make ant quiet without the -q flag? for answers
outputproperty="devnull"
It works fine for me and allways you can print this var if you need.
I have some hudson servers for our CI process.
The build tasks use Ant scripts and also old-school *.bat files.
What do you prefer? What are the pros and cons?
(I think of readability, familiarity to developers and extensibility...)
Are there any other options? We have .Net, Java and PHP apps to test.
Batch is a programming language (and not a very good one at that). Ant is a dependency matrix language. What's the difference?
In a programming language, you specify the order everything occurs in. You're responsible to say what is built and the order.
In a dependency matrix language, you merely state the dependencies, and the program figures out what to do and the order it should be done in. One of the biggest issues developers have with Ant or Make is to try to force a build order instead of letting the build system take care of it.
Builds should always be done with a dependency matrix language like Ant.
Let Ant determine what needs to be built and the order it should be built. Don't use Batch. If you're using Batch scripts to call a bunch of Ant script in the order you think they should be called, you're doing it wrong. Have a master Ant script do it and use <subant> calls. Let Ant do the tricky stuff.
You can use batch script to do preliminary work (such as setting ANT_OPTS if Ant needs more memory, or setting environment variables like ANT_HOME and JAVA_HOME and your %PATH% variable to make sure you're using the correct Java and Ant versions. In Hudson, you can set all of this in the Hudson job itself, so you don't have to call the Batch script.
*.bat files pretty much restrict you to dos/windows, like how shell scripts are for linux, whereas Ant/Maven is cross-platform and gives you the option to use a non-Windows CI server
I'm currently trying to refactor a couple of our ANT scripts and what I'd like to do is try and centralise some of the common targets they use into some kind of shared area.
The target I'm trying to work on just now is configuration. Both our scripts currently have the same code which loads in external properties and sets up our classes.
What I've tried to do is move this target into another build script called configuration.xml and call this through <ant antfile="configuration.xml"> from each script.
What's happening though is the target is running but I can't work out how I can get the values being set to return to the parent build script. Is there anyway I can do that?
Another approach I thought of was to create some kind of "base" script that the other two could inherit from. I don't think that's ideal in the long term but it's an option I thought I could try. Again though I can't find anything online to say ANT can do this.
Depends on what version of Ant you're using as to what methods you have available, but there is the <import file="your-include.xml"/> option.
Here's an example of some imports, if it helps.
http://subversion.assembla.com/svn/cfdistro/trunk/cfdistro/src/cfdistro/scm.xml