I would like to make an ant dependency where the target file depends on a source file. How do you describe this in ant?
For example, convert this Make target to ant
data.txt: header1.txt body.txt footer.txt
cat header1.txt body.txt footer.txt > data.txt
You might be able to do something like this, but it's starting to sound like scripting. Ant isn't a scripting language. If you have a lot of "if/then/else" logic in mind you're probably doing it wrong.
Please describe "other data". Are we talking about copying files? Is this a devl/test/prod environment issue? In that case, you can certainly pass in a parameter specifying environment name and using conditional tests to decide which set to copy. Read this to see how.
If you're just wanting to bring files in one directory up-to-date with respect to your source tree,
you might use the sync task. Here's a basic example from the docs:
<sync todir="site">
<fileset dir="generated-site"/>
</sync>
overwrites all files in site with
newer files from generated-site,
deletes files from site that are not
present in generated-site.
If you need to determine which resources need update,
in order to carry out a more complex operation than a sync,
you might use the ant-contrib outofdate task. For example
<outofdate property="compile.needed" outputsourcespath="sources.for.recompile">
<sourcefiles>
<fileset dir="${src}" includes="*.c"/>
</sourcefiles>
<mapper type="glob" dir="${src}" from="*.c" to="${obj}/*.o"/>
</outofdate>
will set compile.needed to true if any object files are out-of-date compared to source,
and also set the path sources.for.recompile with a list of just the sources that need recompile -
you can then compile for just those sources.
(The assumption here is that a single file in the build output area is directly related to one source.)
My simple solution right now is to manually add a test for the source/dest file age in my shell script called from exec task in ant.
Related
I have a build where a single protomsg source file generates multiple java files.
I want to check whether the files generated are uptodate wrt source file.
For a single target file it works, but it doesn't work if *.java is used.
I need to check it with all files generated.
<target name="stub.uptodate.check">
<uptodate property="stub.uptodate" srcfile="file.blah" targetfile="path/to/targetfiles/*.java"/>
</target>
A simple solution would be checking with a single file among them, but I can't use that now. I did not file any solution with mapper.
There is <outofdate> http://ant-contrib.sourceforge.net/tasks/tasks/outofdate.html , which can handle multiple targets.
I am new to Ant, and having difficulty in understanding some of its basic things like task and target.
Online documentation and books say that target is a stage of the entire build process, while task is the smallest unti of work. However, I find it very difficult to understand what exactly is meant by this,
Can someone explain in depth with examples what are targets and tasks in Ant?
Targets contain one or more tasks.
A target has a user-defined name, and usually does something high-level like "compile the code", or "build a deployable jar file". It is just a convenient container for tasks (and also allows you to specify dependencies upon other targets).
A task is provided and named by Ant (or plug-ins) and is generally something lower-level like "copy a file", "create a directory". You can create new tasks (see the Ant manual) if the built-in ones don't do what you need.
An example from the Ant tutorial:
<target name="compile">
<mkdir dir="build/classes"/>
<javac srcdir="src" destdir="build/classes"/>
</target>
The target is called "compile" (because it is intended to compile some code. However, the name is arbitrary - I could just as well call it "doUsefulStuff"). To complete this target, we specify that we want to execute two tasks:
Make a directory (using the mkdir task)
Compile some code, and put the compiled classes into the directory from step 1, using the javac task
(Disclaimer - it might be possible to create targets with zero tasks - I haven't checked - but they wouldn't be much use).
Another fundamental difference is that when you run ant you indicate a target (not a task) to be executed. So, when you call ant via command line, you specify ant [options] [target]. If you don't specify the target, the one indicated as default in your build file (build.xml) is executed.
If you open an ant build file on the ant view in Eclipse, the executable options are the targets, not the tasks.
For practical purposes, targets are further divided into private (aka, internal) and public. The difference is that the <target> declaration of a public target contains the description attribute. I mention this because you may want to decompose/refactor a target in sub-steps in your build.xml. The sub-steps can be internal targets.
i was writing a custom task for ant in java and my idea was that i can give someone the .jar which contains the java files like the classes and the libraries and the build.xml for ant and he can use it.
If i export my java project the .jar (antTask.jar) contains :
a folder for the compiled classes, one for the libraries, meta-inf folder and .classpath .project files
The ant build.xml looks like this:
<?xml version="1.0" ?>
<project name="repair" basedir="." default="repairTask">
<taskdef name="antTask" classpath="antTask.jar" classname="def.RepairTask"/>
<target....
i don't really understand all this classpath stuff, so can someone tell me what i have to add in my build file so it will work only with this .jar file without the java code sources?
right now i am getting an error that ant can't find one of the libraries i use in the java code with this error (but the antTask.jar contains this lib as another .jar):
taskdef A class needed by class def.RepairTask cannot be found: org/apache/commons/...
using the classloader AntClassLoader[C:...\AntTask\antTask.jar]
i am trying for hours but i just can't figure out how i have to edit my build.xml so i just have to point to this single .jar file and it works..
Thank you guys
All a taskdef does is associate a task name to a classfile that contains the code to execute that task. However, in order to find that classfile, you need to tell <taskdef/> where to find the jar that contains it. That's all classpath does is.
You don't have to define a classpath with the <taskdef/> task. Ant by default looks for all jars that contain code for the <taskdef/> tasks in $ANT_HOME/lib. If you copy your jar to that folder, you could simply define that task this way:
<taskdef name="antTask" classname="def.RepairTask"/>
No need for the classpath. However, I actually don't recommend doing that. Instead, I recommend putting that jar file into your project, so other developers can use your project without having to install that task jar into their $ANT_HOME/lib folder:
<taskdef name='antTask' classname="def.RepairTask">
<classpath>
<fileset dir="${basedir}/antlib/antjar"/>
</classpath>
</taskdef>
Now, when a developer checks out the project that requires the optional task jar, that task jar comes with the project, so they can simply do their build.
There are two ways to define tasks. One is to give a task a name, and then tell <taskdef/> what classfile is associated with that jar as you did above. However, you can also define a resource that also will associate task names with their classes. Here's a common way to include the Ant-Contrib ant tasks:
<taskdef resource="net/sf/antcontrib/antcontrib.properties">
<classpath>
<fileset dir="${basedir}/antlib/antcontrib"/>
</classpath>
</taskdef>
If I expand the antcontrib jar, I'll see it contains a net/sf/antcontrib/antcontrib.properties1 file inside the jar. That file looks something like this:
...
# Logic tasks
if=net.sf.antcontrib.logic.IfTask
foreach=net.sf.antcontrib.logic.ForEach
throw=net.sf.antcontrib.logic.Throw
trycatch=net.sf.antcontrib.logic.TryCatchTask
switch=net.sf.antcontrib.logic.Switch
outofdate=net.sf.antcontrib.logic.OutOfDate
runtarget=net.sf.antcontrib.logic.RunTargetTask
timestampselector=net.sf.antcontrib.logic.TimestampSelector
antcallback=net.sf.antcontrib.logic.AntCallBack
antfetch=net.sf.antcontrib.logic.AntFetch
assert=net.sf.antcontrib.logic.Assert
relentless=net.sf.antcontrib.logic.Relentless
# Math Tasks
math=net.sf.antcontrib.math.MathTask
...
All it does is define each task with a classfile for that task. I would recommend you do something similar with your custom ant task. This way, if you decide to include other tasks, you can simply modify this one file, and developers won't have to change their <taskdef/> definition in their jars, or add in multiple ones.
By the way, you should make good and sure that your class doesn't clash with another class that someone else may use. You might want to give your classname a full path that includes a unique prefix:
<taskdef name='antTask' classname="com.vegicorp.anttasks.RepairTask">
Assuming you work for VegiCorp...
1 Ant contrib tasks contain two such files. One is XML format and the other is in properties format. I always use the XML format, and that's what your suppose to use when you define Ant Task resources. I used the properties file because it's a simpler format and easier to see what's going on.
I'm looking for a way to compile a few flavors of my Java software using Ant. By flavors I mean, for instance, trial and full version.
In the code I have a
public static final boolean TRIAL
variable which specifies whether it is trial or full version. It would be very nice to be able to set it from Ant and to compile both versions automatically.
I could not find a good way to do this, while I do believe that I'm not the first one to face this problem.
In C I would simple use "ifdef" and set the define from Makefile....
Look at this: http://code.google.com/p/preprocessor/
Allows you to do stuff like this:
//#ifdef CUSTOMER1
private String abc = "abc";
//#else
private String abc = "cba";
//#endif
and set it from ant
I'd create a template file and use ANT's copy filters to change the value before compiling. I've never done it with source code, but I've used it quite a bit for configuration files.
In a source template file, you could do:
public static final boolean TRIAL = #TRIAL_VALUE#
Then in the ant build.xml, you could do this:
<filter token="TRIAL_VALUE" value="true" />
<copy tofile="${your.target.file.name.here}" filtering="true">
<fileset dir="${location.of.your.template}">
<include name="${template.file}" />
</fileset>
</copy>
I'm not sure I like the idea of doing this with a real source file (I think there's a good chance it would make the IDE angry). You might want to consider using a configuration file embedded in the jar (and use the copy filter technique on that instead)
If you have several versions of your software to avoid a easy hacking (java decompiler) I strong suggest you the use of parallel set of sources where the trial are just mocks, and so on.
With ANT you could choose the source of exactly what version will use.
Of course that this duplicate the sources, but is one possible solution without use of external software (like previous preprocessor)
With multiple developers working on the same Tomcat application, I'd like to tell the application to install to a different path, based on the current user and revision control client/view.
So, if Bob is building, the app should be installed in Bob's test environment, maybe /bob1 or something like that. Bob might have several revision control clients/views/workspaces he works with so he could have /bob1, /bob2, /bob3, etc.
The install location is specified in the build.properties file. Is there a way to avoid checking that file out and changing it for each specific user and revision control view?
Can "ant install" take arguments or be configured to consider environment variables for the install target?
I typically use a variation on the default properties answer already given:
<property file="local.properties" />
<property file="default.properties" />
I read the local properties file first and the default one second. Users don't edit the default one (then accidentally check it in), they just define the properties they want to override in the local.properties.
You can override ant properties from the command line.
ant -Dinstall.location=/bob1 install
See Running Ant for more information.
This answer is quite late but I just wanted to put it in for someone who may be in need of of it. The answer pertains to the second part of your question.
"Can "ant install" take arguments or be configured to consider environment variables for the install target?"
Define the environment virable in your build file:
<property environment="env" />
reference the env variable and use it to indicate a path. This is done in my classpath definition inside my build file. It says include a jar named api.jar from the weblogic lib directory. You can access any other path so long as there's an associated environment virable defined for it. For example, you can access Program Files, Documents, Java Home etc if you sent environment variables for them. Here the environment variable defined for weblogic installation directory is BEA_HOME
<fileset dir="${env.BEA_HOME}/wlserver_10.0/server/lib">
<include name="api.jar" />
</fileset>
Defining properties with the -D option at the command line is fine, though it can get tedious if there are many of them frequently. In order to resist the urge to wrap the ant invocation in a bash script, there is the common practise to import property files.
In the main build file you put:
<property file="default.properties" />
Then you have a file named default.properties.sample with a sample configuration. This is being checked into version control. The developers check out default.properties.sample, copy it to default.properties and edit it according to their needs.
You should set an ignore default flag for default.samples in order to prevent it from being checked in accidentally (svn:ignore with subversion).