I'm working with a variety of Java EE websites which use internal libraries we've developed. For each website, we only upgrade to new versions of our internal libraries as needed, and before committing we make sure that the site compiles fine.

What this means is that when TeamCity does a build of one of our sites, the site compiles fine, but later when the site is updated to the latest version of internal libraries, there might be a compile error.

Is there a good way to handle this?

We're not using Maven yet; would using Maven mean that our websites could automatically use the latest version of internal libraries?



What we sometimes run into is this:

  1. Project A depends on a library, and is currently using library version 1.0
  2. Project B also depends on that library. I make changes to the library so that it is now version 1.5. Project B now uses 1.5.
  3. Project A and project B have both been built just fine by the CI server (TeamCity)
  4. Working on project A again, I update to 1.5 and discover that 1.5 has breaking changes in it.

Is there a way for the CI server to discover these kinds of breaking changes?

  • """What this means is that when TeamCity does a build of one of our sites, the site compiles fine, but later when the site is updated to the latest version of internal libraries, there might be a compile error.""" - What ??? anyhow, in order to have successful testing, you need to replicate the same steps as a fully staged website would go through. If a continuous integration tool does not help you with it, then write your own Perl/Python/etc. scripts to do exactly what needs to be done, and report ANY errors along the way.
    – Job
    Commented Feb 11, 2011 at 22:56
  • 2
    If you update the library that both projects depend on then doesn't that trigger a build?
    – ChrisF
    Commented Feb 11, 2011 at 23:10
  • Also, this sounds like a once-in-a-year problem. We experience this every 2 years, when upgrading to a newer version of Visual Studio. So, what we do is we upgrade when we are months away from releasing, and we do expect to go through major pain for a day or two. Just how often are these libraries updated? If rarely, then blow away some files/directories manually, and that should trigger another build (hopefully).
    – Job
    Commented Feb 11, 2011 at 23:22
  • 1
    @ChrisF - to include libraries in the projects that use them, we copy over the JAR files by hand... so they aren't automatically brought in. Is there a better way for us to do this? Commented Feb 11, 2011 at 23:29
  • Unfortunately (or fortunately depending on how you look at it) I'm not a Java developer so I don't know how you'd set up dependencies so this would happen. However, I would have thought that if there was a newer version of the file it should trigger something.
    – ChrisF
    Commented Feb 11, 2011 at 23:32

4 Answers 4


Use Maven, it is worth the time to set your projects up to conform to its way of doing things. You also need a local internal repository to deploy artifacts to, I use Archiva. Then you can set your development version to something like version 1.1-SNAPSHOT and that will contain the latest version of that code in development automatically when deployed to Archiva.

You move to fixed Release versions, versions that don't have the -SNAPSHOT suffix for production. If you leave off the <version/> on a dependency it will default to the latest Released / non-snapshot version.

This is all designed very well and works perfectly with Hudson/Jenkins and any other tool that integrates with Maven.


We handle this as part of our build system (SCons in our case). That is, we specify the build dependency against a version of a library. A typical case we hit in our pipeline is that we need to update a plugin for an application, before the application can fully build and install, the correct version of the plugin needs to build and install, and optionally, pass all its unit tests. The advantage to making this a build requirement instead of CI requirement is that then both the developer and the CI system are set with the same constraints, which should make this sort of situation easier.


We used to have issues like that before we switched to maven. For us it solved those issues since you explicitly declare the versions you want to work with. It also gives a lot better visibility into transitive dependencies, which is the issue you are fighting.


Disclaimer: I'm not a Java developer and have never used Maven, so it's entirely possible that it'll invalidate everything I'm going to say below. But it may be useful for non-Java people later on.

If you use TeamCity 6, you could use a command-line runner step in your build that would xcopy the dependent jars over for you.

If you have TeamCity builds configured that produce those internal libraries, you can set up dependencies between your site builds and your library builds such that a successful library build would trigger a site build. If the library build produces jars as artifacts, TeamCity could then pull those jars into the site's build as well.

Another (perhaps worst) option is to check the jars into source control and set up TeamCity to check them out from there for site builds and to trigger site builds when new libraries are checked in.

  • @downvoter How could I improve my answer?
    – Adam Lear
    Commented Feb 21, 2011 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.