18 Replies Last post: Feb 27, 2012 12:21 PM by nodje  
nodje Novice 296 posts since
Nov 4, 2003
Currently Being Moderated

Oct 11, 2011 1:02 PM

6.5.4 : Problem with Maven Snapshot Dependencies...

hi,

 

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?

 

rgds

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Oct 12, 2011 6:42 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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?

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Oct 13, 2011 2:13 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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.

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Oct 14, 2011 2:33 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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.

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Oct 17, 2011 3:03 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

see my reply on your next message

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Oct 17, 2011 3:03 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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:

 

  <mirrors>

    <mirror>

      <id>myRepo</id>

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

      <url>http://my.repository.com/repo/path</url>

    </mirror>

  </mirrors>

 

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 Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Oct 18, 2011 3:25 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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.

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Feb 22, 2012 4:16 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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?

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Feb 24, 2012 2:18 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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.

Sergey Anchipolevsky JetBrains 259 posts since
Jan 22, 2008
Currently Being Moderated
Feb 24, 2012 2:13 PM in response to: nodje
Re: 6.5.4 : Problem with Maven Snapshot Dependencies...

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>

More Like This

  • Retrieving data ...