Question

This is actually two questions, but comes from the same issue:

• We use Jenkins as a Continuous Integration system. Every time someone commits a change Jenkins builds it.
• We use a corporate Maven repository (Artifactory), and all jars we build that are required for other projects we build are stored there.
• I use the Promotion Plugin in Jenkina to promote a Jenkins builds. When I promote a build, I use the mvn deploy:deploy-file command to deploy the jars in that build and their associated POMs back into our corporate Maven repository.
• We actually use Ivy with Ant, but use our Maven repository anyway.

A question has come up. Developer is working on Project B, which uses a jar built by Project A. The developer changes Project A, and then wants to use that changed jar in their Project B.

---

First question

I take it I can use the <ivy:publish> to deliver that jar into that computer’s local repository. Then, when that developer does a build, it will use that version of the jar instead of the jar from our corporate repository.

However, I’ve setup Ivy in such a way that the ivysettings-public.xml has checkmodified set to true. This means that if the repository has a different version of the jar, it will download it even though it’s already in the local repository. How does this affect the ability of the developer to publish jars to their local repository?

When Ivy resolves the dependencies, does it notice that the dependency on the local machine is different than what is in the public repository, so it will always download the public jar, or does Ivy use timestamps? That is, Ivy will see that the timestamp on the local jar is newer than the timestamp on the jar in the corporate repository, and thus won’t download the one in the corporate repository.

If I need to, I can reset the checkmodified back to false, but I’ll have to let developers know they need to clean their Ivy cache on a regular basis to get the latest version of the jars.

Second Question

How do you handle the issue of changes in base jars that could affect other projects?

In my current model (the assumption I made), I expected some sort of workflow on putting these jars into our corporate Maven repository. Someone would create an issue, it would go through a workflow, and I would deploy that jar into our Maven repository.

However, this may just be too restrictive. Maybe deployment of base jars (especially when there’s a lot of development work going on) should be a bit looser.

• I could insist upon this workflow model. I am the CM and my word is law. However, I to set things up, so developers can do their job and not follow a bunch of nonsense procedures.
• I could allow the project leads to do the deployment instead of asking me. This way, they can determine (and take responsibility) for the quality of the jars they promote.
• I can set things up, so Jenkins will automatically promote jars under certain conditions (like they pass all unit testing). I can even combine this with the manual deployment: Developers can promote jars, but only ones that pass unit testing. And, I can even set it up, so that project leads (or just myself) can promote a jar even if the unit testing didn’t pass.

Finally, I’ve setup Ivy at our company, so I have complete control on the ivysettings.xml for all projects (we use svn:externals to pull in Ivy into all projects).

One of the things I could do is setup a second snapshot repository. When a Jenkins build is done, jars can be automatically deployed to this snapshot repository. I could allow the developers to pass an Ant property to the build (either through the command line or via a build.properties file) that will allow the developer to use jars from the snapshot repository before the release repository.

Jenkins could be setup to always deploy newly built jars to this snapshot repository, bur. I would still control the deployment of jars into our release repository. Official (Jenkins) builds will always use the release repository, but developers can use the snapshot one if needed.

Answer 1

We took another lead with Maven and create snapshot versions upon each and every build. I create both a pom-snapshot.xml and a pom.xml with each jar that gets built via the <ivy:makepom/> task.

I have two promotions: One promotes the snapshot version and the other promotes the release version (same jar really). The snapshot promotion runs after each successful build. The release promotion takes place manually. This way, we can promote jars into our release repository, but still allow developers to play with the latest jar.