ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: AW: What should be downloaded
Date Thu, 20 Sep 2007 15:16:29 GMT
Bruce Atherton wrote:
> wrote:
>> Is that ok?

> Wow, quick work. Thanks, Jan, that looks great. I have a few minor edits 
> and wanted to get the subdirectory info in there, but I'm having 
> Subversion issues today so I'll have to check in the changes later.
>>> and not all Ant users are programmers. Thanks.
>> ??? really? What are the other scenarios (for non-developers)?
> Well, I can think of several groups that I've seen running it. One is 
> sysadmins that use Ant for various deployment and system maintenance 
> tasks. They may even be responsible for keeping a build machine running 
> for developers. They are technical, yes, but not necessarily programmers.
> Another group is QA testers who may use Ant to automate testing, 
> particularly with tools like Canoo WebTest[1] or with a custom built 
> system.
> Yet another is anyone installing an application that requires the 
> running of Ant to perform or complete the installation. Any application 
> distributed using Ant Installer[2] or Antigen[3] would fit into this 
> category, to name just two.
> Then there are all the document handling solutions such as the one Mark 
> mentioned in his email. Ant is ideal for hiding multiple XSLT transforms 
> and just "building" output documents from input XML. XML Publication[4] 
> is another example of this.
> Those are just a few examples that spring to mind. I'm sure there are 
> many others.

Testers are a special case...they are part of the dev team, but they 
shouldnt be assumed to know about XML namespaces, class not found 
exceptions, etc, only about the systems they test.

I think all my work this week has been on ant and RPM creation, with no 
line of java code involved. Instead its all creating rpm files and shell 
scripts that work. And how do I know they work? In the build, I scp them 
over to a vmware image of RedHat enterprise linux 5 and install the 
rpms, then walk the initd through its operations

   <target name="rpm-remote-initd" 
       description="check that initd works">
     <rootssh command="${remote-smartfrogd} start"/>
     <rootssh command="${remote-smartfrogd} status"/>
     <rootssh command="${remote-smartfrogd} start"/>
     <rootssh command="${remote-smartfrogd} status"/>
     <rootssh command="${remote-smartfrogd} stop"/>
     <rootssh command="${remote-smartfrogd} stop"/>
     <rootssh command="${remote-smartfrogd} restart"/>
     <rootssh command="${remote-smartfrogd} status"/>
     <rootssh command="${remote-smartfrogd} restart"/>
     <rootssh command="${remote-smartfrogd} status"/>
     <rootssh command="${remote-smartfrogd} stop"/>

then I go on to issue some rpm commands to make sure all directories are 
explicitly owned by the rpm, otherwise some distros dont make them 
accessible to non-root users

   <target name="rpm-queries-test" depends="rpm-remote-install"
       description="check that files and directories belong to the RPMs">
     <expandingcopy file="${rpm.metadata.dir}/rpm-queries.txt"
     <rootssh commandResource="${build.dir}/rpm-queries.txt"

where the rpm-queries file is a list of directories and files we expect 
to have
rpm -qf ${rpm.install.dir}
rpm -qf ${rpm.install.dir}/bin
rpm -qf ${rpm.install.dir}/lib
rpm -qf ${rpm.install.dir}/links
rpm -qf ${rpm.install.dir}/bin/security
rpm -qf ${rpm.install.dir}/bin/metadata
rpm -qf ${rpm.log.dir}
rpm -qf ${rpm.etc.dir}
rpm -qf ${rpm.install.dir}/testCA
rpm -qf ${rpm.install.dir}/private
rpm -qf ${rpm.install.dir}/signedLib
rpm -qf /etc/profile.d/
rpm -qf /etc/profile.d/smartfrog.csh
rpm -qf ${rpm.install.dir}/docs
rpm -qf ${rpm.install.dir}/src
rpm -qf ${rpm.install.dir}/

So, No Java. It is a java system we're publishing, but this build file 
is there to build Linux RPMs and test them, using remote SSH commands to 
a linux system hosted in its own VM to test it. The nice thing about 
this approach is it scales out to different linuxes, just with new VMs.

I'm actually thinking of using AntUnit to run these actions as unit 
tests, just for the better reporting. Right now the thing blocks on the 
first failure, whereas I could make every rpm -qf query its own test 
target, I could make different initd sequences their own stuff too. That 
would be slick, wouldn't it. Remote install of your RPMs and test 
results presented junit style, even on a CI server.

Steve Loughran        
Author: Ant in Action 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message