詹金斯·哈德森（Jenkins Hudson）建造问题

Question

I am new to Nexus and Ant. I have success in generating components through Jenkin Hudson build jobs that are ant driven. We have SVN as the source repository.

The issue here is that, all the components are getting created again into the nexus repository when I am running the Hudson job. Lets say I have 5 jars in my applications and I have change in only one class file corresponding to a specific jar. Instead of creating only the jar that is having the change, all 5 jars are getting created every time.

Is there some settings as Jenkins that will help me achieve what I am looking for .. Or is this something that needs to be controlled through ant build.xml ?

Appreciate your help in advance.

Answer 1

There's a bit more to your setup than you allow us to know.

First, you say Ant , but you're using a Maven repository. Are you using Ivy? Or, do you use the <wget> task to download the jars?

How do you deploy your jars to your Maven repository? Do you use an Ant plugin, a Jenkins plugin, or do you use mvn deploy:deploy-file ? Do you do this in your Jenkins job definition or do you use something like the Promoted Build Plugin or Repository Connector Plugin ?

Finally, what exactly is the problem? Is it a problem with deploying jars to your Nexus repository? Is it a problem with the Jenkins job rebuilding all five jars? And, why is this a problem? What are the issues if a jar is redeployed to your Nexus repository? Does it take too much time? Can you configure Nexus not to run the deploy if the checksum of the jar has not changed?

Also, why are you building five jars in one project. Could you make it five separate Jenkins jobs, and only build jars where the source gets changed?

---

Addendum

Application builds a single war and bunch of jars that are external to the war. They remain outside the war. I have a java web application XXX. On running the build job on this application, I will get abc.war and aaa.jar, bbb.jar, ccc.jar. There jars to be created are mentioned in the build.xml.

Here's how we handle this issue. It may take a bit of setup for you.

First, we use Ivy with Ant. Ivy allows us to use Maven dependency management without having to completely restructure our build process.

Each jar is a separate project in our Jenkins server. The jar gets rebuilt when the code for that jar is changed. Not knowing how your repository and projects are structured, it may be harder for you to do this.

If your war is setup to call separate build.xml for each jar, it shouldn't be too hard to do this. If you have a single build.xml, but separate targets for each jar, and each jar has its source code in a separate tree, it'll be a bit tricker. You can setup Jenkins to checkout/update the entire project source code, but only look at the source code in a particular directory to see if a rebuild is necessary. If the source code for all the jars are intermingled in a complex way, it'll be harder to do.

We use the Jenkins Promoted Build Plugin to deploy the built jar to our Maven repository. This gives us a bit more flexibility to decide when jars are deployed. Our standard practice is to deploy snapshot versions after each build (to let developers play around with the latest features), but use release versions in our war.

When a new release of a jar is deployed, we set it up, so that any project that depends upon that war is automatically rebuilt.

When we build a war, we don't build the jars, but use <ivy:retrieve> to retrieve the required jars from our repository.

So:

• We only build the jar if the jar's source itself has changed.
• We build the war by downloading the required jars. If you don't clean the cache between each build, only changed jars will be downloaded.
• We setup Jenkins to fire off a war build if one of its dependent jars have been modified.
• When the war builds, it only downloads the changed jars, and then builds any classes, etc. it has.
• If you structure your project correctly, Ant will only build what was changed. However, we do a clean and Subversion update, so we do rebuild the entire project, but don't have to redownload the entire project. Since wars only have to download the changed jars, and build what java code they use, it doesn't take a long time to rebuild wars anyway.

I hope this helps.

One more thing...

You can try not cleaning out your build detritus between builds on Jenkins. Use use updates only in Jenkins to only update source files that haven't been changed. Ant will automatically not rebuild stuff that hasn't been changed. This means that unchanged *.java files won't recompile, and *.jar files won't rebuild if their components haven't changed.

However, you must make sure your build.xml is bullet proof and well structured. Otherwise, you'll end up with a lot of hurt. The first six months at my current work, I rewrote all of the build.xml files to make sure they were well structured and will do build avoidance. You may have a lot of work to get this to work correctly.