ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Burgess, Benjamin" <>
Subject RE: shared ant installation
Date Tue, 03 Jun 2008 14:09:49 GMT
We use a similar strategy more like what DD is describing.  At the top
of our "Master Build Script" which everyone's script imports, we have
these tasks (some are from ant contrib) declared outside of a target (so
they always run):

	<get src="http://an.internal.web.server/"
dest="${user.home}/.ant/" ignoreerrors="true"
	<loadfile srcFile="${ant.home}/etc/our.version.txt"
property="our.ant.version" failonerror="false"/>
			<equals arg1="${our.ant.version}"
			<splash showduration="1000"

We added a couple extra files in our Ant distribution's etc folder
including an image that says to go check for an updated ant distribution
and a version.txt file that has a number in it that we increment
whenever we update the distribution.  The get task keeps local copies of
the file up to date and the hardcoded version number in
that should match the number in the ant distribution's
version.txt file (otherwise, you know there is an updated ant
distribution available).


-----Original Message-----
From: Dominique Devienne [] 
Sent: Monday, June 02, 2008 6:42 PM
To: Ant Users List
Subject: Re: shared ant installation

On Mon, Jun 2, 2008 at 4:44 PM, Shawn Castrianni
<> wrote:
> After more investigation, I guess it isn't even getting to my import.
I think it is dying on just trying to invoke ant from a Windows UNC
path.  If I just type:
> \\<serverName>\dir1\dir2\dir3\ant\bin\ant
> it gives me the same error as before.  Is it possible to run ant from
a network share on windows?

\\server\dir is not a valid URL, and thus Java/Ant has trouble with it
(in the low level URL/URI code). Depending on the JDK sometimes
file:/server/dir is the proper URL, sometimes its file:///server/dir.
(You could also have them map the remote dir to a drive letter, to
work around the UNC path name issue).

But wanting developers to use a non-local Ant sandbox, brrrr, that's a
no-no to me. By this thinking you'd want them to work in a code
sandbox you dynamically update yourself without their knowledge, or
why not have them use a remote JDK install to make sure they are using
the right patch of the JDK (too many times I've seen variation on this
where you work Shawn ;-)

Just trust your developers to update the CVS or SVN maintained sandbox
of your build stuff often, after you've told them. Possibly add
"enforcement", by comparing the version of your stuff embedded into
downloaded dependencies with the local one, and fail on mismatch. Or
have the build check your "master" sandbox's version and fail on
mismatch. Better these strategies than the shared sandbox approach

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

This message, including any attachments, contains confidential information intended 
for a specific individual and purpose, and is protected by law. If you are not the intended

recipient, please contact the sender immediately by reply e-mail and destroy all copies.
You are hereby notified that any disclosure, copying, or distribution of this message, or
the taking of any action based on it, is strictly prohibited.


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

View raw message