I would like each of my Git repositories to have their own build.xml file, but avoid having to copy paste a lot of macrodefs used by the different build scripts.
What would be the best way to organize this?
Adding the ant macrodefs to a seperate Git repository and make them available for all the build projects on my Jenkins server?
Adding them for instance to a directory of the Ant installation folder?
Does anybody have some experience with this kind of setup?
I do the same. I feel strongly that every project should be stand-alone and not depend on another source code repository. To achieve this I package my common macrodef's as an ANTLib. These are simply jar files that can be imported into the ANT build like other 3rd party tasks.
The following answer explains how to create an antlib:
How to manage a common ant build script across multiple project build jobs on jenkins?
The really big advantage of this approach is when you save the ANTlib jar in a versioned repository like Nexus. I use ivy to manage my dependencies and this allows my common build logic to be versioned, enabling me to safely change logic without breaking older builds. When you think about it this is the same kind of workflow implemented by Maven (which also downloads plugins).
Related
I have workspace with n projects. I want to use ant to build all the projects with one command. The projects are depend on each other
For example project A depends on project B, so I want B to compile first When I compile project An I need to use B's project classpath.
The dependencies between the projects are represented in a ivy.xml file
The main challenge is that I have my own repository where all those projects have artifacts, and using the example I just gave Project A compiles against the B project coming from my the repository and not Against the B project that just was compiled.
I use CI process and I don't want to publish any project to my repository before all of them compiled and the the the QA tests was passed
What is the best practice build several projects with dependencies using ant?
You can combine the ivy buildlist task with subant to build the sub-projects in the correct order, based on dependencies.
See the following answer for an example:
ivy simple shared repository
Using this approach it's possible to re-create how Maven works without switching build tools.
You can spend a significant amount of time fighting ant and ivy in order to achieve what you want, or you could just use Maven or Gradle which will handle all of this for you automatically.
We are looking into adopting a more CI friendly approach to managing our on premise jar dependency file server or doing away with it entirely for a better alternative. Right now it is just a Linux server with some form of file structure for example:
http://server_name/vault/apache.org/axis/version_number/axis.jar
http://server_name/vault/apache.org/axis/version_number/jaxrpc.jar
http://server_name/vault/apache.org/axis/version_number/axis.jar
Was wondering what type of standard adopted enterprise CI practices for managing these dependencies when you are doing automated builds.
Would storing them in AWS S3 be a good idea?
Are there any applications that help manage the jar dependency library? (Looking for open source solutions preferably). For example something similar to where you simply add a jar you need, and pull it down using an API when doing a build.
Assuming that apache ant is used for building out the project. And if that doesn't play well in the CI realm, what would be a good alternative?
I would recommend using Apache ivy to manage your build's dependencies. Ivy can be configured to pull your dependencies from Maven repositories which is pretty much the defacto standard now for storing Java binaries.
Use public maven repository with ivy
Maven Central is the largest repository of Java binaries. To host your private binaries there are various ready made options: Nexus, Artifactory or Archiva
Am very new this kind of S/W development industry and since am here as system engineer, my task is to implement a Build and Release management system using Jenkins. So, far am able to install, configure and even build the war files for my java proj using maven after checking out the sourcecode from my svn. Now the actual task it to build mutliple war file for the same proj for my different environment like UAT, Staging and Prod. I dont want to create multiple jobs, however I would like to use the multi-configuration option to achieve this. So, can anyone please help me in doing this?
Thanks,
Sree
I strongly advise against building environment specific release binaries. Instead address what it is that makes one environment different from another. Generally it is configuration held in property files recording information like:
Database URLs and credentials
System sizing information
..
Baking this into the release makes your software very inflexible. For example why should you have to rebuild your software everytime the database password is changed?
The solution is the use of standards like JNDI. In tomcat you can use context files to set datasources and other variables.
I want to use the same targets defined in an external file in multiple build definitions. This external target file should be stored on the source control.
The bootstrap phase explained in TFSBuild.proj and Importing External Targets does not seem to allow downloading the same file for multiple build definition as the build file is always named TFSBuild.proj and consequently sits in a separate folder for each build definition.
The question was somewhat aked in a comment of the previouly mentionned thread but it seems motre appropriate to create a new thread.
Quoting that comment by David Keaveny:
Is it possible to get TFS to download
from other folder paths during
bootstrap? I have a Common.targets
file that contains all the custom
tasks that my TFSBuild.proj should be
executing, but given that I several
build definitions (one folder per
definition), it sits in a separate
folder at the same level as the build
definitions. Without it, of course,
the builds fail immediately. – David
Keaveny Aug 17 '10 at 23:58
I'm not sure if there is an easy way to do this. You could have a master copy of the targets file, and branch that in to each of your build definition folders. When you update the targets file you'd need to remember to merge it to all of the folders. You could probably write a script that automates the merging, the script should be able to work out what the branching relationships are using tf branches and then iterate around them and call tf merge then tf checkin. This feels like a lot of work though.
You could just install the target on your build server(s). We have a number of custom targets that we use and we manage them as if they were a product, they have their own area for source control and are versioned independently of the software they are used to build. We package them using wix and once they have been tested they are installed on all of the build machines. This seems to work for us and it means we can control the rollout of new targets files, and the targets install is just part of a build server basline build.
I'd be very interested if someone has an easier way of managing this though.
At my new gig, they use Ant and cannot be persuaded to move to Maven.
I've looked everywhere for a decent example of how a multi-project ant build system should be assembled. The apache site falls short. I'm looking specifically for best practices to:
Automatically build local projects that are dependencies of a project
Share artifacts from project to their dependents
Export a project's dependencies and generated artifacts (jars) to be inherited by dependent projects
Share third-party dependencies between projects
I'm sure I can do all this without using Ivy - what did people do before Ivy? I really don't want to have to set up a corporate repository or rely on external repositories - the engineers here are really against that and have all their third-party jars checked into src control.
Can anyone point me at a good open source example of a multi-project ant build?
I don't have too much hands on experience with building large numbers of dependent projects with Ant, but this tutorial looks like it will do what you need without any additional tools.