I have a set of java projects coming from different git repositories which I want to be built with Jenkins.
All of them share the same ant build script, which employ
A couple of ideas...
This answer is not specific to Jenkins and should be portable to other build servers.
I have also found another option myself:
Declare the "overrideable" part in the common build script as "neutral" element, e.g. for a path definition define an empty path:
<path id="additional-classpath" />
Optionally import another build script after the neutral defintion to make it override the existing one:
<import file="compile-classpath.xml" optional="true" />
In the imported file you now can define the element to suit the individual needs of the project to build.
Not an uncommon problem as @whiskeyspider states it's not confined to Jenkins. In my opinion it's also one of the issues that holds backs large legacy ANT builds. Over time it gets harder and harder to change the common logic due to a justifiable fear that it breaks dependent builds.
Keeping the common logic in a separate repository or a git submodule is sound advice because it enables version control of this logic. Another option is to package the common logic as an ANT lib
<project ... xmlns:common="antlib:com.example.commonbuild">
<taskdef uri="antlib:com.example.commonbuild">
<classpath>
<fileset dir="${lib.dir}" includes="commonbuild-1.0.jar"/>
</classpath>
</taskdef>
..
..
<target name="build">
<common:compileAndPackage srcDir="${src.dir}" buildDir="${build.dir}" jarFile="${build.dir}/${ant.project.name}.jar"/>
</target>
While it appears more complicated I maintain creating these kinds of common tasks makes for a more reusable and readable build file. It also makes it obvious what your organisation's customisations are. I find it especially useful for hiding implementation details that might involve nasty embedded scripts.
Finally I'm a big fan of using ivy for managing my 3rd party dependencies. This means I can easily download whatever version of the common logic my build needs from my repository.
├── build.xml
└── src
└── com
└── example
└── commonbuild
└── antlib.xml
<antlib>
<macrodef name="compileAndPackage">
<attribute name="srcDir"/>
<attribute name="buildDir"/>
<attribute name="jarFile"/>
<sequential>
<mkdir dir="@{buildDir}/classes"/>
<javac srcdir="@{srcDir}" destdir="@{buildDir}/classes" includeantruntime="false"/>
<jar destfile="@{jarFile}" basedir="@{buildDir}/classes"/>
</sequential>
</macrodef>
</antlib>
Note:
Just jar up the XML file:
<target name="build" description="Create jar">
<jar destfile="${build.dir}/commonbuild-${version}.jar" basedir="${src.dir}"/>
</target>
My build logic additionally would publish this jar file into my repository, so that other builds can pull it down using ivy. Also means that the common build logic can have a separate and formal release management life-cycle (Very important in a large organisation)