I want to rename my application folder with a time stamp and then unzip a newer version of my app using the same folder name. Using the Ant (move task), it looks like you can move contents from one folder to another.
Is this the only way I can do this in Ant?
The move task does do what you're after, but the naming is a bit confusing. If you consider your directory is a 'file' in the Java sense - a file being a filesystem handle that can represent, among others a directory or a file in the usual sense - then the move task makes sense.
So the following
<move file="mySourceDirName" tofile="myTargetDirName"/>
means rename/move the directorymySourceDirName to be instead myTargetDirName.
The following then
<move file="mySourceDirName" todir="someExistingDir"/>
means to move the directory mySourceDirName to become a child directory of the existing someExistingDir directory.
So, in ant the 'file' attribute refers to the target in question, and the 'todir' attribute refers to the directory that is the new parent location for the target file or directory.
Just spelling out the answer already given, which is correct...
<project default="move">
<tstamp/>
<target name="move">
<move file="foo" tofile="foo-${TSTAMP}"/>
</target>
</project>
This moves foo to foo-HHMM.
For example:
$ find .
.
./build.xml
./foo
./foo/bar.txt
$
$ ant
Buildfile: C:\tmp\ant\build.xml
move:
BUILD SUCCESSFUL
Total time: 0 seconds
$
$ find .
.
./build.xml
./foo-1145
./foo-1145/bar.txt
$
If you want to rename folder, you can use move tag but it there is a cryptic way to use it. As #phasmal said you can use move but it moves the folder inside the desired folder. If you just want to rename, try following.
<move todir="newname">
<fileset dir="directory tobe renamed "/>
</move>
I think the move task is what you want. Is there some reason you don't want to use it?
It sounds like you're proposing moving the folder in which your build.xml file lives. Is that right? If so, I imagine ant might not be too happy it.
Related
Ant seems to be ignoring one of my properties files.
<property file="local.properties" />
<property file="build.properties" />
build.properties contains the typical properties my team wants to use. I'm introducing local.properties which contains overrides for my specific workstation. We're using Eclipse for this project (I'm using Kepler), but regardless of whether I build in Eclipse or build via the command line the build fails because it is using some values in build.properties even though local.properties contains overrides.
In my specific case, my version of Java is newer than the other developers/environments. Despite specifying the version I have in local.properties, it still tries to use the compiler for the version in build.properties.
I know the values are fine because if I put my local properties in build.properties everything works.
Eclipse doesn't care about your build.xml or your properties files. That's only with Ant.
Try running ant with the -d flag, and capture STDOUT and STDERR. This will show you whether or not the local.proeprties is being read in and what values are set. It will say whether or not it's attempting to read local.properties, whether it found local.properties, and if so, what properties are being set.
Also remember that properties are set first come/first serve. You didn't say where in your build.xml you're reading in local.properties. It could be that this is being read in a target while other properties are set outside of targets. Even if they appear later in the build.xml file, properties set outside of any target are set first. If these are set, and you read in local.properties, local.properties isn't going to over ride them. I mention this because it was a problem I ran into here. Someone had a bunch of <property/> tasks placed at the end of their build.xml,and they didn't realize that these would be set before any target was run.
Again, try this:
Unix and Mac:
$ ant -d 2>&1 | tee ant.out # Allows you to see and capture the results
Windows
$ ant -d > ant.out 2>&1 # There's no "tee" command in Windows.
The output of ant.out will be thousands of lines long, but it'll help you figure out what's going on. What you post looks correct.
Hi I have the following directory structure...
I enter this at terminal:
javac -d bin src/com/elharo/math/Fraction.java
and the Fraction.class file gets placed in bin/com/elharo/math instead of bin/
I just wondered why the compiler placed the file there. Is it that the point of having source and bin, so that when you compile a source file it goes in the parallel/mirror bin directory?
The output path will be computed from package and class name of the public class that must be defined in the java source file (which must, incidentally, match the file name minus ".java"). And it will be relative to the directory in the -d option, or relative to the current directory.
This is as expected. /com/elharo/math is the package the class exists in. If you took the class out of this directory an just put it in bin you would like get a noclassdeferror.
I'm trying to build a Mac OS X bundle application automatically.
When copying the file "/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/JavaApplicationStub" of kind "Unix Executable File" with the copy tag:
<copy file="${stub.file}" todir="${dist.dir}/${ant.project.name}.app/Contents/MacOS"/> and getting a file of kind "Document" and the bundle doesn't execute. If I copy it from Finder it works fine.
Is there a way to copy it and keep it's kind with ant?
Thanks in advance!
The file ist copied correctly, but the execute permission ist lost as described in the ant manual:
Unix Note: File permissions are not retained when files are copied; they end up with the default UMASK permissions instead. This
is caused by the lack of any means to query or set file permissions in
the current Java runtimes.
You have to use the cp command or change the permission later with chmod:
<apply executable="chmod">
<arg value="a+rx"/>
<file file="${stub.file}" basedir="${dist.dir}/${ant.project.name}.app/Contents/MacOS"/>
</apply>
I'm having an extremely strange problem with ant. This snippet produces a set of files with the correct names and timestamps, but with obsolete contents.
<target name="inflate-workspace">
<copy todir="${rns.workspace.dir}" preservelastmodified="true" >
<fileset dir="${git.dir}/azia" />
<fileset dir="${git.dir}/scrap-menagerie" />
</copy>
</target>
The resulting timestamps in toDir correctly match those in the filesets, but the contents of each file is about 2 days old. I activated the verbose flag and manually verified that the source and destination directories are correct. I also manually deleted the toDir and ran the target in isolation, to be sure nothing else weird was happening. Running cp -R ... with the exact same directories works perfect.
The environment is Debian on VBox, hosted in Windows 7. Google turns up nothing related to "ant copy obsolete file contents" or anything like it... anyone heard of such a thing? Please let me know, it's really a bother to have ant copy broken!
Try adding overwrite="true" to your copy command.
The problem here is that ant 1.8.0 was simply broken. I can't imagine why it was ever posted, or why it's still in synaptic for Debian. What a horrible bug... hacky apache.
Check for .class files that could be left forgotten and delete them before building next time with ant.
Of course it can be done using the exec task, but my question is:
Is it possible to do it using the tar task?
I don't think there is a way to retain existing permissions, per this note from the copy task:
Unix Note: File permissions are not retained when files are copied; they end up with the default UMASK permissions instead. This is caused by the lack of any means to query or set file permissions in the current Java runtimes. If you need a permission-preserving copy function, use <exec executable="cp" ... > instead.
However the tar task can take one or more tarfileset elements. The tarfileset can be defined with a filemode and/or dirmode attribute to specify the unix permissions. If you specify multiple includes matching only those files to get each set of required permissions, the files in that set will be included with those permissions.
It is impossible. This lack of permission makes ant tar task almost useless for me. There's no way to do it without executing the operating system tar with the exec task:
<exec executable="tar" output="/dev/null" os="Linux">
<arg value="--exclude-from=files_to_exclude.txt"/>
<arg value="-cvz"/>
<arg value="--file=${file.tar}"/>
<arg value="."/>
</exec>
There are gnu tar binaries for almost all operating systems known to man. Put one of them in your version control system and use it depending in your operating system. Yes, Ant will need to fork a process every time it is run.
Using tarfileset worked for our project. Here's a working example in case someone needs it:
<tar destfile="${dist}/${module.name}-${version}.tar">
<tarfileset dir="${package.dir}" filemode="550" includesfile="${home.dir}/includelist.txt">
<include name="*.sh"/>
</tarfileset>
</tar>
In this example, includelist.txt is used to tell which files to include in the tar file. All the files with *.sh extension will have Read and Execute permission (550) for the user and the group.
Hope this helps someone.