6.5.4 : Problem with Maven Snapshot Dependencies...


I've updated to 6.5.4 to solve what I understood was a bug : the recurring apperance of the red message: 'Problem with Maven Snapshot Dependencies... ' in every build that has a Maven Snapshot trigger.

I still have it on many maven builds, I don't understand what's causing it

Couldn't perform check for SNAPSHOT dependencies update because there was an error reading POM. See Maven 2 tab for details
« Hide stacktrace
jetbrains.buildServer.buildTriggers.BuildTriggerException: Couldn't perform check for SNAPSHOT dependencies update because there was an error reading POM. See Maven 2 tab for details
at jetbrains.buildServer.maven.trigger.MavenArtifactTriggerBase.checkJobStatus(MavenArtifactTriggerBase.java:96)
at jetbrains.buildServer.maven.trigger.MavenArtifactTriggerBase.triggerBuild(MavenArtifactTriggerBase.java:50)
at jetbrains.buildServer.serverSide.impl.BuildTriggersChecker.triggerBuilds(BuildTriggersChecker.java:45)
at jetbrains.buildServer.serverSide.impl.BuildServerRunner$4.doSomething(BuildServerRunner.java)
at jetbrains.buildServer.serverSide.impl.BuildServerRunner$BuildServerWorker.run(BuildServerRunner.java:10)
at java.lang.Thread.run(Thread.java:662)
Caused by: jetbrains.buildServer.maven.trigger.CheckJobCreationException: Couldn't perform check for SNAPSHOT dependencies update because there was an error reading POM. See Maven 2 tab for details
at jetbrains.buildServer.maven.trigger.SnapshotsCheckJob.<init>(SnapshotsCheckJob.java:66)
at jetbrains.buildServer.maven.trigger.MavenSnapshotDependencyTriggerService$1.createJob(MavenSnapshotDependencyTriggerService.java:42)
at jetbrains.buildServer.maven.trigger.MavenArtifactTriggerBase.checkJobStatus(MavenArtifactTriggerBase.java:87)
... 5 more

Caused by: jetbrains.buildServer.maven.metadata.MavenMetadataNotAvailableException
at jetbrains.buildServer.maven.metadata.impl.MavenMetadataBean.getActualMavenProject(MavenMetadataBean.java:79)
at jetbrains.buildServer.maven.trigger.SnapshotsCheckJob.<init>(SnapshotsCheckJob.java:41)
... 7 more

Can you tell me what's missing? What is TC actually looking for?



This error means TeamCity couldn't read POM. This is needed for analizing project snapshot dependencies and checking them for updates.
The exact reason why TeamCity was unable to read POM is visible on the "Maven 2" tab of the build configuration page.

Could you please describe what is reported in there?


Sorry, I forgot to check that despite the clear message, I guess I believed updating to 6.5.4 would magically solve the problem...

The same error for all builds: the parent POM isn't found

An error occurred during collecting Maven project information: Cannot find parent: com.company:company-parent

Parent pom has to be installed manually on each every agent - afaik due to Maven limitations.

Which is precisely the original point of my question in Getting a build to run on all agents by default.

How does the server resolve the Maven dependencies? Does it has it's own bundled Maven, does it use its user's own .m2/repository ?
Can I point it to another - in my case the local buildAgent - .m2/repository.

I'm afraid to have to install manually yet another paren pom instance.


on the Maven 2 tab for the parent pom build, I've got the following error.

An error occurred during collecting Maven project information: Unable to build project '/opt/local/apache-tomcat-6.0.26/temp/teamcity1800547576466275045maven/pom.xml; it requires Maven version 3.0.1

Which confirm the TC server bundled Maven instance.

Is it possible for the TC server to use M2_HOME env var as well? Couln't find any place to configure this in Administration section.


TeamCity parses poms using bundled Maven 2.2.1 as a library. Unfortunately you cannot switch to any arbitrary Maven since it's bound to 2.2.1 too tight. When resolving parent dependencies TeamCity uses it's own local repository located in <TC data dir>/system/pluginData/maven/repository . Currently it's not possible to point TeamCity to another location.
You can put the missing parent pom into there. But why you don't deploy the parent into the corporate repository so the server and all agents could pick it without having you to install it into each machine?

As for Maven 3.0.1 limitation error. How did you get this restriction? As far I as know both Maven 2 and 3 use the same project model version, so even if a project is intented to be built with Maven 3, it at least should be readable with Maven 2.


There's always been a problem with the parent pom.
It needs to be installed manually, it doesn't behave as a dependency, it's not updated like them.

Besides, it needs to be deployed first, so that dependant project can find it.

How can I install the parent pom in the server repository, and how can I make that a TC build?

We use the maven restriction to 3.0.1 to be sure everyone in the team has the same Maven revision.
It's possible to remove it, though TC shouldn't impose things like that.

Server bundled Maven definitely needs to be externalized in the future. Is it a planned feature already?


Sorry, I don't understand the difficulties with your parent pom quite well. Here at JetBrains we have a parent pom for several projects deployed into our repository manager, and we have no problem accessing it when either building any project or reading it in TeamCity provided the settings.xml defines appropriate mirroring. Yes, it should be deployed first, but that's all you need to make your projects get built (+ mirroring).

If you still want to manually install that pom to the server local repository, you can do it by executing install:install-file (http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html)

> Server bundled Maven definitely needs to be externalized in the future. Is it a planned feature already?

We don't plan to externilize it, but yes, we're considering to use both Maven 2 and 3 engines for parsing poms on server.


Hello Sergey,

we've always had problems with the company parent pom.
We decided it had to be installed manually on each every machine. There's probably a way to get an update in the dependency SNASHOT style.

Would you mind telling me how you use the mirroring? I don't see how it can help in this matter.



How can I have the server local maven to execute the install:install-file ?

I can't use a Maven build step since I don't have a pom.xml, can't use a script build with 'mvn' either, I guess I need to find the bundled maven executable.

There's nothing in <TC data dir>/system/pluginData/maven/ but artifactDigest.xml.
Where's the .m2 repository then? The Maven executable?

I need a TeamCity build to be able to install this parent pom, I'll have to install it every now and then in the future.
I guess a script build with a reference to the bundled maven excutable should do the job.



There is no bundled Maven installation on the server, only on agents. The server uses only few Maven jars.
You don't see the repository directory since (most likely) teamcity hasn't required it yet. It's created automatically on demand.

Simply Install Maven 3 on server manually, then manually execute the following command (you don't have to have ./pom.xml for executing this)

mvn install:install-file -Dfile=<path to your parent pom> -DpomFile=<path to your parent pom>  -DlocalRepositoryPath=<TC data dir>/system/pluginData/maven/repository

Of course you can make TeamCity do this. You will have to setup an agent on the server machine then, since the server itself doesn't execute builds.

But again, to me deploying this pom to the corporate repository and using mirroring is much simpler solution.

To setup mirroring just add to the settings.xml the following:

      <mirrorOf>*</mirrorOf> <!-- this wildcard means mirroring of all possible repositories -->

Your repository manager should be configured as a proxy for all required external repositories like Maven Central etc. This way a request for any dependency or parent pom will be redirected to http://my.repository.com/repo/path and will be fulfilled by your repository manager provided it's properly configured.

You also should propagate these settings among all agents (~/.m2/settings.xml) and the server (<TC data dir>/system/pluginData/maven/settings.xml)

Note that this is the simplest possible configuration which you may tune according to your needs and constraints.

Sergey, thank you for for all your explanation.
However, I can't understand what mirrors could bring to me compare to Repositories in the parent pom.

That's what I use in the parent pom:


I designed it this way so that any newcomer in the team wouldn't have to do any config - not even in maven - but just to install the parent pom first.

That seem to be exactly what mirrors propose to do in my opinion. I don't see the difference honestly.

Basically each user of a machine still has to have it's own repositories, and where the problem lies.

I'll have to get my parent pom in the server repo even though there's an agent on the machine (and many users for that matter) that already has a maven local repo.

Technicaly your solution is close to what I propose. But in general I prefer mirroring because a parent pom usually contains more information than just a repository list. Once it contains more information, it (usually) changes more frequently. This is the point where settings.xml looks better. For instance, if you change the dependencyManagement section or add a profile in the parent pom, with mirroring you just deploy the updated pom to the corporate repository and it will be automatically updated on every location. Without mirroring you have to update it on each location manually, which can be quite a big and error prone activity.

Of course, if you don't consider such changes probable in your case, both solution look pretty similar - you either put settings.xml or install the parent pom - not a big difference.


Took me a while but I finally found the time to implement your solution.
It works great and I'm very happy with it.

All Teamcity SNAPSHOT dependencies are now solved. And I get a ton more build triggered as you can imagine!

A side problem I'm having right now is that when a build is triggered because of a SNAPSHOT dependency, it is triggered on each agent, instead of being triggered only once.
It doesn't seem possible to control this on the Build Triggering section.

Where can I configure this?


Sorry, I don't quite understand "it is triggered on each agent". A build always runs only on a single agent, which is chosen automatically and can be overriden by you. Or you mean multiple builds are triggered on the same update of a SNAPSHOT artifact?



this is exactly what I meant, sorry for being unclear.
Multiple builds "were" triggered on the same update of a SNAPSHOT.

Can't reproduce it today though, so far so good.
But it seemed a consistent behavior yesterday... I had this 3 times, the build history shows a build per agent, just a minute appart from each others...

Please disregard


A note about Maven server settings.xml in TC-7.0

I just upgraded to TC-7.0
Found the Maven Settings in Administration:

It says 'There are no Maven settings files.' and propose to upload a new file.

Just before upgrading I put a settings.xml in <teamcity data>/system/pluginData/maven

Shall I upload settings.xml once more or is it taken into account already?


This is probably because the deployment of multiple artifacts is not an atomic operation and takes some time, and the checking for updates happens in the middle of it. It can be avoided by using Artifactory and its plugin for TeamCity, which supports atomic deployment. You also can mitigate the problem by increasing the poll interval, though this won't completely resolve the issue. By default the interval is set to 10 minutes. You can override it by placing the following line into the <TC data dir>/config/internal.properties

teamcity.maven.artifactTrigger.checkInterval=<your value in seconds>


This is a new feature of 7.0. You can upload a number of different settings files and then select any of them on the Maven runner page. During a build TeamCity transfers it to the agent and push it to Maven, so you don't need to do it manually and keep it in sync with the server. But this doesn't affect your current approach so you don't have to change anything if you don't want to.


Interesting, I now understand the value of the Artifactory plugin compared to the maven 'deploy' goal...

"You can upload a number of different settings files and then select any of them on the Maven runner page" >> simply awesome, wasn't obvious just looking at the upload page.



Please sign in to leave a comment.