Bruce Atherton wrote:
[EMAIL PROTECTED] wrote:
Is that ok?
http://svn.apache.org/viewvc/ant/core/trunk/docs/manual/install.html?view=diff&r1=577182&r2=577183&pathrev=577183
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"
depends="rpm-ready-to-remote-install,rpm-remote-install"
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"/>
</target>
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"
todir="${build.dir}"/>
<rootssh commandResource="${build.dir}/rpm-queries.txt"
failonerror="true"/>
</target>
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/smartfrog.sh
rpm -qf /etc/profile.d/smartfrog.csh
rpm -qf ${rpm.install.dir}/docs
rpm -qf ${rpm.install.dir}/src
rpm -qf ${rpm.install.dir}/src.zip
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 http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
