TeamCity, Maven, Classifier, and maven-metadata.xml

Hello,

Thank you in advance for any assistance, I'm completely out of ideas. I'm using TeamCity 6.5.2, the changelogs that I saw to 6.5.5 do not seem promising for this problem. Also, this may be a maven deploy plugin or archiva issue, any opinions are welcome.

My setup looks like this (mostly because of matlab licensing fun):

pom.xml <modules=A,B,C>
\A <pom file + java code>
\B <pom file + java code>
\C <pom file + java code>
\D pom.xml <modules=E,F,G>
\D\E <pom file + matlab code>
\D\F <pom file + matlab code>
\D\G <pom file + matlab code>

So when I build my root pom.xml, by default, it builds A, B, and C.

When I build D, it builds E, F, and G.

When building D it deploys OS-dependent jars for E, F, and G to an apache archiva repository. This is done by specifying the classifier tag in the maven-jar-plugin in the \D\pom.xml file:

<build>

          <plugins>
               <plugin>
                    <artifactId>maven-jar-plugin</artifactId>
                    <version>${maven.jar.plugin.version}</version>
                    <configuration>
                         <classifier>${envClassifier}</classifier>
                    </configuration>
               </plugin>
          </plugins>
</build>

where envClassifier is defined in the root pom.xml file depending on the current operating system (we deploy windows and linux jars, both 64-bit).

I've also updated the maven-deploy-plugin version in the root pom.xml file to version 2.7 and referenced the classifier, without this the deployed maven-metadata.xml file did not have the <versioningSnapshot> information needed to resolve dependencies and only the last deployed OS jars were found.

    <build>
        <plugins>
               <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-deploy-plugin</artifactId>
               <version>2.7</version>
               <configuration>
                    <classifier>${envClassifier}</classifier>
               </configuration>
          </plugin>
        </plugins>
</build>



Now we come to my problem. I have 4 build TeamCity configurations, 1 that builds A on windows, 1 that builds A on linux, and 1 that builds D on windows and 1 that builds D on linux. Building D (and thus E, F, and G) is done by manually triggering both the linux and windows build configurations simultaneously (I've also tried back to back, same results) to get the same svn revision #. About 1/2 the time everything goes swimmingly and there are no issues. The other half of the time the deployed maven-metadata.xml file seems to lose all its <versioningSnapshot> information, so I end up with the below as my maven-metadata.xml. It has been very difficult to ascertain when the maven-metadata.xml file gets corrupted, it seems somewhat random. Recently I have seen it get corrupted after a *deploy* on A, but looking at that build's log it doesn't show any uploading of E, F, or G's maven metadata. So I really don't know why it keeps getting hosed and after it's hosed dependencies cannot be resolved.

<metadata>
     <groupId>com.foo</groupId>
     <artifactId>E</artifactId>
     <version>4.0-SNAPSHOT</version>
     <versioning>
          <snapshot>
               <buildNumber>325</buildNumber>
               <timestamp>20111205.181820</timestamp>

          </snapshot>

          <lastUpdated>20111205181820</lastUpdated>

     </versioning>

</metadata>

Instead of something like:

<metadata modelVersion="1.1.0">
     <groupId>com.foo</groupId>
     <artifactId>E</artifactId>
     <version>4.0-SNAPSHOT</version>
     <versioning>
          <snapshot>
               <timestamp>20111205.200259</timestamp>
               <buildNumber>328</buildNumber>

          </snapshot>

          <lastUpdated>20111205200259</lastUpdated>
          <snapshotVersions>
               <snapshotVersion>
                    <extension>pom</extension>
                    <value>4.0-20111205.200259-328</value>
                    <updated>20111205200259</updated>

               </snapshotVersion>
               <snapshotVersion>
                    <classifier>linux</classifier>
                    <extension>jar</extension>
                    <value>4.0-20111205.200259-328</value>
                    <updated>20111205200259</updated>

               </snapshotVersion>
               <snapshotVersion>
                    <classifier>tests</classifier>
                    <extension>jar</extension>
                    <value>4.0-20111205.200259-328</value>
                    <updated>20111205200259</updated>

               </snapshotVersion>

          </snapshotVersions>

     </versioning>

</metadata>


Any help or advice is tremendously appreciated. In case it matters, we're using maven 3.0.3, CentOS and Win2003 both 64-bit, and JDK 1.6.

Cheers from Virginia.
Jason

6 comments
Comment actions Permalink

Hi Jason,

I have only two guesses -- it is build concurrency or a bug in Archiva. As for the first one (not sure, however, if this ever had a place in your case), try giving each build configuration a separate local repository using -Dmaven.repo.local=xxxx
As for the other, try a different repository manager like Artifactory or Nexus. 50% reproduction rate is high enough to see just soon if any of my assumptions is true

0
Comment actions Permalink

Thank you so much Sergey. I will try both of your suggestions when I get back to work. Cheers & Merry Christmas!

0
Comment actions Permalink

Hi Sergey,

I've removed all multithreading from my run (I was using the -T argument) and I've moved over to the latest sonatype and TeamCity. Unfortunately I still get the same build failures. If I deploy windows jars then the linux build cannot find it's jars because it is looking for something like "E-1.0-20120124.003257-7-linux.jar" (the windows build did deploy E-1.0-20120124.003257-7-win.jar) but the last linux one to deploy was "E-1.0-20120124.003101-6-linux.jar".

Is anyone out there able to support both windows and linux specific builds with one TeamCity build server and 1 maven repository?

0
Comment actions Permalink

Hi Jason,

Did you try making builds with separate local repositories as I suggested before?

0
Comment actions Permalink

Hi Sergey,

Yes, I gave each agent their own private maven repository. In fact, I just went all out and gave each agent their own private maven installation with a modified settings.xml file for each agent that points to their own private local .m2 repository.

0
Comment actions Permalink

Hi Jason,

I must admit I'm out of ideas too. We don't use Maven for our own developement here at JetBrains and don't know many of its subtleties. There are chances TeamCity is involved but I just don't see how. Probably your tricky combination of artifact coordinates is improperly handled by Maven deployment logic. I suggest you putting this question into the Maven user list (users@maven.apache.org). Sonatype guys are usually give answers quite fast.

If you do so, please let me know if TeamCity is to blame.

Thank you.

0

Please sign in to leave a comment.