Gents,
Thank you for any assistance in advance. I'm completely out of ideas,
as are the folks at TeamCity. This may be a maven deploy plugin issue,
all opinions/insights are welcome and appreciated. At the very highest
level I need to be able to continuously deploy linux and windows jars
and let a build running on either linux or windows resolve those
deployed jars.
My setup looks like this (mostly because of matlab licensing fun):
pom.xml <modules=A, B>
\A <pom file + java code>
\B <pom file + java code>
\C <pom.xml + modules=D, E>
\C\D <pom file + matlab code>
\C\E <pom file + matlab code>
So when I build my root pom.xml file I do a mvn deploy at the root
which deploys A and B. When I do a mvn deploy on C it deploys D and E.
B and C need the jars from D and E. When doing a mvn deploy on C
OS-dependent jar files are deployed to an apache archiva repository
(I've tried sonatype, had the same issue, so I don't think it's an
archiva problem). The OS-dependent specification is done by adding the
classifier tag in the maven-jar-plugin in C's pom.xml:
<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, only
64-bit).
I've also updated the maven-deploy-plugin version in the root pom.xml
file to version 2.7 (I tried the latest snapshot too, to no avail).
The updated maven-deploy-plugin also references 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 full force to the issue at hand. I have 4 TeamCity build
configurations, 1 that deploys A on windows, 1 that deploys A on
linux, 1 that deploys C on windows, and 1 that deploys C on linux.
Deploying A is done continuously on every commit (if the build agents
can keep up, A is a fast build). Deploying C on windows and linux is
(currently) done by manually triggering the build on the build server
such that they both start at the same time and therefore are
(hopefully) based on the same svn revision (we average a commit every
~20 minutes, so that seems ok for now). Most of the time the deployed
maven-metadata.xml file seems to eventually get corrupted and loses
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 log it doesn't show any updating of C, D, or E's maven
metadata. So I really don't know why it keeps getting hosed and after
it's hosed dependencies cannot be resolved when building A on either
linux or windows (but not both, whichever OS last deployed, that OS
build for A can still resolve dependencies). Also the "good"
maven-metadata.xml file only seems to have 1 classifier, so maybe
that's not even good enough? i.e. In the "Good maven-metadata.xml"
example below there is only a "linux" classifier.
Hosed maven-metadata.xml:
<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>
Good maven-metadata.xml:
<metadata modelVersion="1.1.0">
<groupId>com.foo</groupId>
<artifactId>D</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>
I have tried giving each TeamCity build agent their own private maven
repository and even private apache mvn executable.
Any help, guidance, or advice is greatly appreciated. We are using
maven 3.0.3, CentOS for linux and Win2003 both 64-bit and JDK 1.6_30.
We deploy from all our build agents with "mvn clean deploy". With the
C project we specify the pom to be C's pom file since TeamCity cannot
checkout the A directory and cd into the C directory and then issue
the deploy command.
Cheers from Florida,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
