maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Cservenák <ta...@cservenak.net>
Subject Re: Maven 3.0.3, Classifier, maven-metadata.xml, <versioningSnapshot>, and TeamCity
Date Thu, 09 Feb 2012 11:58:11 GMT
Hi there,

disclaimer: am from Nexus team (you mentioned Nexus in your story).

you problem is exactly as you point out with "hosed" and "good"
metadata: loss of information because something downgrades your
metadata.

Note the "modelVersion" attribute in "good" metadata. By "downgrading"
(the "bad" one is implicitly having "old" version), you suffer from
information loss, that information that you actually need for this
build. This change of metadata happened with Maven3.

In short, _something_ is downgrading your metadata.

As for Nexus, it should not touch your metadata (it will store it
as-is on deploy), UNLESS you explicitly ask it to "recreate" maven
metadata OR you use group to access it on older version of Nexus.
Versions post 1.9.0 (see NEXUS-3849) will create "new" format
(modelVersion=1.1.0) and should not cause information loss.

Since you do not mention Nexus version you tried in this story, this
most I can help here.

For Archiva, unsure what it does with Maven metadata, but I bet
someone from it's team will chime in ;)


Thanks,
~t~

On Wed, Feb 8, 2012 at 9:11 PM, Jason H <wherisat@gmail.com> wrote:
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message