I am new to ant and Ivy. We are using Jenkins for CI with ant for builds, Ivy for dependency manger. We have several modules/projects which generate jars and wars, which can be independently versioned and released (not all modules will be released at the same time), so, need to maintain version number separately for each module. We want to use the version format A.B.C.D (ex: 1.2.1.2). I found I can use a property file to enter a version number and use ant BuildNumber task to increment the number for our nightly builds. So, once all the features are in and tested we move the last successful nightly build as new released version but we want to change the version number without rebuilding it. For example last successful build was 1.2.1.20 and it was tested thoroughly and has all the feature, we have to make this build from 1.2.1.20 to 1.3.0.0 without rebuilding the modules. How can I do that using ant? And also I need to publish them to my shared repository with the version 1.3.0.0. How do I do that?
Also, we want to create a zip file for each module with all dependency files along with the module's jar file for delivery. Is there any ivy or ant tasks that can help to create this?
I think you've asked two questions...
Generally, every build I create is releasable so I'm always incrementing the last digit in my release number scheme. For controlling the version number I prefer to use the ivy buildnumber task, which increments based on what has been previously pushed to your repository (very useful).
Creating a zip package is quite straight forward. Just alter your ivy file to publish more than one artifact.
Related
I wanted to know if we have a plugin or can we write a pre delivery script that will change the value of packaging in my pom file. I want it updated from jar to pom. Can a plugin help with this? Suggestion welcome.
I tried-and-tested with maven profiles but do not want to go that route.
When you deliver in RTC, all you are doing is making your file available to any repo workspace monitoring the common Stream.
If you need to make some change to a pom.xml (without using profiles), then it is simpler to publish (that is add, commit and deliver) as well a script which would:
copy the pom.xml
change it as you need
use it with a mvn -f pom-modified.xml
The point is, as mentioned in this thread:
There is no out of the box solution for enforcing any pre-deliver steps.
You can try and add an RTC extension, as described in "RTC: Build On Deliver Participant" by Jorge Díaz.
$ ant clean compile notexist install
Here I get BUILD FAILED because notexist doesn't exist as a target, which is expected. But is there anyway to just ignore or skip unknown targets? Or maybe map unknown targets to a known target (which would be a no-op for me)?
Background
We are using Atlassian Bamboo for our CI server, and whenever we want to add an ant target to our build, we run the risk of breaking older branches of code. This is because if we run an old build through our CI, it may not contain the target and therefore fail. Thus we are reduced to editing the build.xml file, and either use depends or <ant>, but this doesn't give us the flexibility we desire.
Example
Today we have:
ant clean selenium.tests
We want to add a new target to test our REST services. Target is rest.tests. Thus, I want my command to be
ant clean selenium.tests rest.tests
But for old branches, rest.tests doesn't exist yet. Our solution up to now has been to add rest.tests as a dependency of selenium-tests (since our build.xml is under version control), but this means we can't run selenium.tests by itself.
In hindsight, we should have just created a proxy target, such as integration.tests (we already use test for unit tests) which would delegate to both of these two targets. But unless there is a solution to my original question, we can't even add integration.tests to the CI.
You may have to invoke ant programmatically. Discussed here in Running ANT Programmatically Through Java
The org.apache.tools.ant.Project provides list of targets and way to invoke it
I don't think there is a way to test that a target (rather than a file) exists as you call it. My suggestions are:
How often do you build old versions which have missing targets? If it sufficiently infrequent that you can take the pain of manually commenting out those calls in the CI config?
Can you limit your CI calls to a tidy set which will generally be there: clean, build, test, dist etc?
Do you need to split the CI config into multiple jobs? If you really need targets which aren't there in some versions maybe you have radically different versions of your product that merit separation into different CI jobs. Then it won't make sense to build the job for which the target doesn't exist.
My problem is the following:
I would like to use the propertyregex task in ant. The project I am working on is built on various different servers and I don't want to configure (install the ant-nodeps.jar) every server. The source needs to include everything, that is not installed on the system by default.
So now I would need to add the ant-nodeps.jar to the ant classpath from within the build file. Does somebody know how to do that?
Cheers,
Robert
The propertyregex task is part of ant-contrib and can be installed as part of your build using Apache ivy
Checkout the following example, which demonstrates how to download and use the "for" task (also from the ant-contrib project):
Problems getting my ANT builds to work after OS upgrade
The one downside is that ivy does not come pre-packaged with ANT, so the following answer has a tip on how to bootstrap your ANT builds. Once ivy is started it can be used to pull down everything else your build needs.
Ivy fails to resolve a dependency, unable to find cause
Update
While I understand you requirement to have no change on the target platforms, it's a very difficult problem to solve if you must also match several old versions of the build software. I have found incompatibilities between the latest ANT and 5 year old versions like 1.7 (ANT 1.6.5 is now 8 years old....)
What I do is install a very limited number of ANT versions on my Jenkins slave nodes. Build jobs can then only choose from these and then use ivy to download all other 3rd party software dependencies (This setup emulates how you'd manage a set of Maven projects).
I suspect you're using ANT to run your deployments? If that is the case I would suggest switching to something like Groovy, which can be deployed as a single jar file and can pull down dependencies on the fly, using Grape.
I have a Java project that is dependent on other Java projects that are siblings and there is a chain of dependencies. Each individual project has a build script written in Ant. For clarity find below a sample of the same.
EARProject depends on WebProject and EJBProject: The war file that is generated by the WebProject build and jar file that is generated by the EJBProject are needed to build the EARProject.
WebProject depends on ComponentOneProject: The jar file that is generated by the ComponentOneProject build is needed to build WebProject.
EJBProject depends on ComponentTwoProject: The jar file that is generated by the ComponentTwoProject build is needed to build EJBProject.
So, when I build the EARProject build, if the dependent war and jar have not been built yet, then it should kick-off the WebProject build and EJBProject build and if the ComponentOneProject is yet to be built, the build of ComponentOneProject needs to be kicked-off and so on.
Can someone suggest a clean method by which we can accomplish this?
Facing the same problem we at our company wrote a custom Groovy script that explores the full dependency tree ant generates the Ant build scripts based on all the .project, .classpath, .settings/* files. This wasn't as difficult as it might seem as first. This way we can build our products without (My)Eclipse on a clean CVS+JDK+Groovy virtual machine. Hope it helps..
Are there any tools available that allow the cleanup of a ant script?
I especially need to remove unecessary jar files... The Ant script I have to clean has more than 500 entries and has grown uncrontrolled over time.
There's no automated way of cleaning up jar files. You can look at the various include statements in your Java code, but they merely mention classes to include and not the jar themselves. Even if you can determine that a particular class is served by jarA.jar, it could be that jarA.jar is dependent upon jarB.jar.
You can even start removing jar files one at a time to see what breaks your build. That can be somewhat automated, especially if you specify your classpath via fileset instead of each specific jar. However, what if you actually need a jar for runtime, and not for the build?
My suggestion is to use Ant with Ivy. Ivy gives you the same Maven jar dependency capabilities without converting your project to Maven.
Take a look at Ivy and see how it works with Ant. Then, if possible, ask your developers to determine exactly what jars they need and what versions of those jars they need. You will have to help them. You might have to go through the jars in your repository and attempt to figure out what versions of the jars are in your repository.
You don't have to worry about jars that other jars depend upon. Ivy will take care of that for you. What you simply need are the jars that your developers depend upon, and they should know because they're the ones who use the include statements in their programs to specify a particular dependency.
Once you've determined the primary jars (and revisions) you need, you can easily convert your build.xml files to take advantage of Ivy's jar dependency system. Once you've done that, you can remove all the jars from your source repository since Ant with Ivy will download the required ones from the Internet based Maven repository system.