We have a large amount of apps. They all have a build.xml file located in the projects base directory. I am trying to create an ant script that will go through and call a specific target on each of the build.xml files in all the projects.
Here are the issues:
Some of the projects are in deeper directories than others.
Only some of the projects need to be built at a time.
I was trying to use subant + antfile and defining a CSV of file paths in a properties file, but this did not work. Below is what i have and the error i am getting.
If there is a better way to do this or you know what my problem is, please let me know! Thanks!
This is the property defined in a property file. I am wanting the person running the script to add the file paths in here that are relative to the current location of the script they are running.
projects.to.build=
This is the subant task i am trying to use in the main build script.
<filelist
id="projectNames"
dir="${basedir}"
files="${projects.to.build}"
/>
<target name="debugAll" description="Builds all the projects listed in the projectNames.properties file.">
<subant target="debug" antfile="${projects.to.build}">
</subant>
</target>
Here is the error i get when i try to run the build script when there are projects defined in the properties file. I am using the relative path. For example: ..\Apps\AnApp1\build.xml,..\Apps\AnApp2\build.xml,..\OtherApps\foo\AnotherApp1\build.xml
"No Build Path Specified" (at my subant task)
You specified the antfile attribute, so ANT was expecting to a single build.xml file.
The subant documentation describes how you can use a fileset as child parameter.
Here's an example:
<project name="Subant demo" default="run-debug-target">
<target name="run-debug-target">
<subant target="debug">
<fileset dir="." includes="**/build.xml" excludes="build.xml"/>
</subant>
</target>
</project>
Update
Alternatively a filelist could be used:
<project name="Dry run" default="run">
<target name="run">
<subant target="test">
<filelist dir="projects" files="one/build.xml,two/build.xml,three/build.xml,four/build.xml"/>
</subant>
</target>
</project>
Processing the following build files:
projects/one/build.xml
projects/two/build.xml
projects/three/build.xml
projects/four/build.xml
Is it possible to run the target in the all the build files concurrently ?
E.g.
<project name="Dry run" default="run">
<target name="run">
<subant target="test">
<filelist dir="projects" files="one/build.xml,two/build.xml,three/build.xml,four/build.xml"/>
</subant>
</target>
</project>
In this example, is there any way to run target "test" present in all the build files (one/build.xml,two/build.xml,three/build.xml,four/build.xml) concurrently ?
Related
To my surprise the build.xml file generated by Eclipse (Neon) for Java has no element containing an invocation of a jar task. As often is the case with code generation I think you have to use it and make no edits so that you can regenerate - or - avoid code generation completely. A comment in the generated file suggests it might be possible to avoid edits by extending the capabilities by importing.
<!-- WARNING: Eclipse auto-generated file.
Any modifications will be overwritten.
To include a user specific buildfile here, simply create one in the same
directory with the processing instruction <?eclipse.ant.import?>
as the first entry and export the buildfile again. -->
I thought I would be able to use the <?eclipse.ant.import?> element in an second file called export.xml. In ant scripting there is supposed to be one project per buildfile so now there is a second project with a dependency on a target in the first project.
Regenerating build.xml reveals that it contains an "import" as expected.
<import file="export.xml"/>
Unfortunately this does not work. Running ant, which I do from the command line, just seems to result in the export/jar project being ignored.
The generated script with the import element (nested on the 7th line)...
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project basedir="." default="build" name="ohana1">
<property environment="env"/>
<property name="debuglevel" value="source,lines,vars"/>
<property name="target" value="1.8"/>
<property name="source" value="1.8"/>
<import file="export.xml"/>
<path id="ohana1.classpath">
<pathelement location="bin"/>
<pathelement location="../export/ohana1/commons-collections-3.2.1.jar"/>
</path>
<target name="init">
<mkdir dir="bin"/>
<copy includeemptydirs="false" todir="bin">
<fileset dir="src">
<exclude name="**/*.launch"/>
<exclude name="**/*.java"/>
</fileset>
</copy>
</target>
<target name="clean">
<delete dir="bin"/>
</target>
<target depends="clean" name="cleanall"/>
<target depends="build-subprojects,build-project" name="build"/>
<target name="build-subprojects"/>
<target depends="init" name="build-project">
<echo message="${ant.project.name}: ${ant.file}"/>
<javac debug="true" debuglevel="${debuglevel}" destdir="bin" includeantruntime="false" source="${source}" target="${target}">
<src path="src"/>
<classpath refid="ohana1.classpath"/>
</javac>
</target>
<target description="Build all projects which reference this project. Useful to propagate changes." name="build-refprojects"/>
<target description="copy Eclipse compiler jars to ant lib directory" name="init-eclipse-compiler">
<copy todir="${ant.library.dir}">
<fileset dir="${ECLIPSE_HOME}/plugins" includes="org.eclipse.jdt.core_*.jar"/>
</copy>
<unzip dest="${ant.library.dir}">
<patternset includes="jdtCompilerAdapter.jar"/>
<fileset dir="${ECLIPSE_HOME}/plugins" includes="org.eclipse.jdt.core_*.jar"/>
</unzip>
</target>
<target description="compile project with Eclipse compiler" name="build-eclipse-compiler">
<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/>
<antcall target="build"/>
</target>
</project>
The export.xml file meant to make a jar...
<?eclipse.ant.import?>
<project basedir="." default="export" name="ohana1Export">
<target depends="build,make-jar" name="export"/>
<target name="make-jar">
<jar destfile="../export/ohana1/${ant.project.name}.jar" basedir="bin"/>
</target>
</project>
Note that the Eclipse Ant editor complains about this export.xml file because the target named build, which is a dependency, does not exist in this project/buildfile. The build target is in the generated build.xml. That error might be coming from a "dumb" editor so I went ahead to do a run of ant. Invoking ant from the command line I find that there is no jar file made.
Should I conclude that Eclipse's ant script generator is useless if you need to export a .jar file and that a human should maintain the ant script that meets all the requirements?
Yes, in my opinion the exported build.xml is useless, as of Eclipse Neon, if the intention is to make a .jar.
Specifically do the following.
Manually write the trivial ant script that exports a .jar. The link at the bottom of this post has verbatim text on what the script might look like. You can use the built-in Xml Editor via New > Other > XML > XML File to create this new file which might be called makeJar.xml and save it. If the icon shown in the Package Explorer is still a plain XML file icon refreshing the project may change the icon to an Ant file icon. In the future, you can use Open With to get the Ant Editor instead of the XML Editor. This script will replace the manual exporting of a .jar that the user would otherwise perform via Eclipse.
This script can be added to Project > Properties > Builders. It would be placed second in the list of Builders. First in the list of Builders is the Java Builder which should already exist. When an Eclipse build is invoked the entire list of Builders will be processed in the order shown in the list of Builders. Thus not only will .class files be generated but also the .jar.
What is achieved is greater automation since the .class generation and .jar generation are now integrated, which arguably was the point of using the exported build.xml in a failed attempt to generate the .jar.
Here is the dialog at Project > Properties > Builders that you can use to create a new Builder. Select New then select Ant Builder. I gave the name makeJar to the new Builder.
Here is the dialog for the new Ant Builder that will allow you to browse to your buildfile which is your manually written Ant script that creates a .jar file. In this example the script is makeJar.xml. It also allows you to browse to the base directory to be used when the script is run.
After setting up the new Builder, a project "clean" or project "build" will create .class files and also the .jar.
Eclipse's documentation on this subject is at the link. Note that it seems impossible to link the exact page that contains the instructions so you have to browse down the documentation tree to the section about "Ant buildfiles as project builders".
Link to Eclipse and Ant
I have a javascript project with the following structure:
root -
/docs
/dist
/source
/resources
/plugins
Code is in source directory and an ant script is executed to generate compressed files in dist directory. All the files are in source control.
I want to run a directory diff before running the ant script to make sure the list of files in source and dist directories are same. If not, stop execution and tell the user to checkin the needed files before running the build.
I am new to ant and am unable to find any documentation to list differences in files list between 2 directories. Appreciate any inputs.
You could try the following. Prints a list of the files to be checked in before failing:
<project name="demo" default="build">
<target name="check">
<apply executable="echo" failonerror="false" resultproperty="files.found">
<arg line="missing file:"/>
<srcfile/>
<fileset id="srcfiles" dir="source" includes="*.txt">
<present present="srconly" targetdir="dist"/>
</fileset>
</apply>
<fail message="Files need to be checked in" if="files.found"/>
</target>
<target name="build" depends="check">
..
..
..
</target>
</project>
Note:
Tested on Linux. Probably won't work on windows.
I have to create a single command to create multiple(dev|qa|uat) war/ear.
Something like :
ant -f build.xml -Denv=dev|qa|uat -propertyfile= devProp|qaProp|uatProp
-Dstage.dir=devdir|qadir|uatdir
I already have different properties file, different staging, deploying target for each environment. I also have different .cmd files to build each of them separately.
What I am stuck at is: How do I build them all in one go?
You can use the <subant /> instruction in your target.
Write down a new ant script (namely master.xml), assuming that your original build is in script build.xml, you can have something like:
<target name="build-all">
<subant target="build-prod">
<fileset dir="." includes="build.xml"/>
<propertyset ......../> <!-- properties for the prod build -->
</subant>
<subant target="build-dev">
<fileset dir="." includes="build.xml"/>
<propertyset ......../> <!-- properties for the dev build -->
</subant>
</target>
I have several build files which all import the same base build file, like this:
base.xml:
<project name="base">
<!-- does not define a 'build' target -->
</project>
buildA.xml:
<project name="buildA">
<import file="base.xml" />
<target name="build">
<ant antfile="buildB.xml" target="build"
inheritall="false" inheritrefs="false" />
</target>
</project>
buildB.xml:
<project name="buildB">
<import file="base.xml" />
<target name="build">
...snip...
</target>
</project>
(Module A depends on module B.)
Now, the above calling of B's build target from buildA.xml gives the following error:
Duplicated project name in import. Project base defined first in buildA.xml and again in buildB.xml
Since both buildA.xml and buildB.xml inherit the same base.xml, this seems unavoidable.
How could I get rid of this error?
Based on sudocode's answer, I solved the problem. Because the absolute path to base.xml is different in both cases, Ant does not recognize it as the same file. Even though inheritAll is set to false, the context of the calling task is preserved and this causes the name clash.
To solve this, one can omit the name attribute from base.xml. Since Ant 1.8, the import task has an attribute as, which can be used to reference base targets when the base project is nameless. If you don't override any targets, you can use include instead of import. I'm on 1.7, so that does not help me.
For previous versions of Ant, you can go through an exec call to prevent proliferation of the Ant context entirely (then you get two running Ant instances). Better yet, find a way to import the exact same base.xml (with the same absolute path) in both files.
Are you using Ant 1.6? This resolved Ant bug looks like the same issue.
EDIT
I tried to reproduce the dir structure you refer to in your recent comment.
./base.xml
./buildA
./buildA/buildA.xml
./buildB
./buildB/buildB.xml
And amended the build files accordingly, e.g.
<project name="buildA">
<import file="../base.xml"/>
<target name="build">
<ant antfile="../buildB/buildB.xml" target="build" inheritall="false" inheritrefs="false"/>
</target>
</project>
I still get no build error for the following with ant 1.8.2 or 1.7.1:
ant -f buildA/buildA.xml build
I am new to ant i referred many sites , i need to build.xml for my project which consists
of two modules i have application.xml file which represents corresponding war file
so my question is it sufficient to add the application.xml file
<ear destfile="${dist.dir}/${ant.project.name}.ear" appxml="${conf.dir}/application.xml">
<metainf dir="${build.dir}/META-INF"/>
<fileset dir="${dist.dir}" includes="*.jar,*.war"/>
</ear>
whether this will refer the corresponding war files or i need to compile the whole scenario please let me know. how solve this.
I'm not 100% sure what you're asking.
In order to use the <ear> task, you already need to have compiled the required jars and wars.
If those jars and wars have already been built, you simply refer to them in your <ear> task as you did in your example. The application.xml must already exist before you build your ear. The application.xml doesn't build the jars and wars, you have to do that.
If you haven't already built the wars and jars, you need to do that first. A general outline of a build.xml looks something like this:
<project name="foo" basedir="." default="package">
<!-- Some standard properties you've defined -->
<property name="target.dir" value="${basedir}/target"/>
<property name="xxx" value="yyy"/>
<property name="xxx" value="yyy"/>
<property name="xxx" value="yyy"/>
<!-- Compile properties that allow overrides -->
<property name="javac.nowarn" value="false"/>
<property name="javac.listfiles" value="false"/>
<property name="javac.srcdir" value="source"/>
<property name="javac.distdir" value="${target.dir}/classes"/>
<target name="clean"
description="cleans everything nice and shiny">
<delete dir="${target.dir}"/>
</target>
<target name="compile"
description="Compiles everything">
<mkdir dir="${javac.distdir}"/>
<javac srcdir="${javac.srcdir}"
destdir="${javac.destdir}"
[...]
[...]/>
</target>
<target name="package.jar"
depends="compile"
description="Package jarfile">
<jar destfile="${target.dir}/jarname.jar"
[...]
[...]/>
</target>
<target name="package.jar2"
depends="compile"
description="Package jarfile">
<jar destfile="${target.dir}/jarname2.jar"
[...]
[...]/>
</target>
<target name="package.war"
depends="compile"
description="Package jarfile">
<war destfile="${target.dir}/jarname.jar"
[...]
[...]/>
</target>
<target name="package"
depends="package.jar"
description="Make the ear">
<ear destfile="${target.dir}/earfile.ear"
[...]/>
</target>
</project>
Basically, it consists of a bunch of targets and each target does one task. You can have targets depend upon other targets. For example, this particular build.xml will automatically run the package task. The package task depends upon the package.jar task which depends upon the compile task. Thus, the build.xml file will first call compile, then package.jar, then package.
The important thing to remember is that you don't specify the order of the events. You let Ant figure that out, and you let Ant figure out what you need to do. Let's say you've modified a java source file. Ant knows that it has to recompile only that one file. It also knows that it might have to rebuild the jarfile that contains that classfile. And, it then knows it has to rebuild the ear. Most tasks can figure it out on their own, and you don't do a clean for each build. (You notice that the clean target isn't called by package or compile. You have to call it manually).
The only other thing I recommend is that you try to keep your work area clean. Any files you create should be put into the ${target.dir} directory. That way, when you do a clean, you only have to delete that one directory.
I hope this answer your question.