2012-05-10 1 views
6

私のjava/Mavenプロジェクトは、私のジェンキンスとネクサスレポでフックアップされていますジェンキンスMavenはネクサスにjarファイルを展開 - 「testproject」と呼ばれるアーティファクト命名

私のpom.xmlは、次のようになります。

....  
<distributionManagement> 
    <!-- use the following if you're not using a snapshot version. --> 
    <repository> 
     <id>nexus</id> 
     <name>RepositoryProxy</name> 
     <url>http://nexus:8080/nexus/content/repositories/releases</url> 
    </repository> 
    <!-- use the following if you ARE using a snapshot version. --> 
    <snapshotRepository> 
     <id>nexus</id> 
     <name>RepositoryProxy</name> 
     <url>http://nexus:8080/nexus/content/repositories/snapshots</url> 
    </snapshotRepository> 
</distributionManagement> 
...... 

設定私のジェンキンスさんは、私が持っている:

予想通り
Build - maven3 - clean deploy 

は、ジェンキンスさんはジェンキンスからのコンソール出力でNexus.Lookにアーティファクトをアップロードビルド、以下のように:

[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ testproject --- 
[INFO] Building jar: /var/lib/jenkins/workspace/testproject/target/testproject-0.1-SNAPSHOT.jar 
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ testproject --- 
[INFO] Installing /var/lib/jenkins/workspace/testproject/target/testproject-0.1-SNAPSHOT.jar to /var/lib/jenkins/.m2/repository/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1- SNAPSHOT.jar 
[INFO] Installing /var/lib/jenkins/workspace/testproject/pom.xml to /var/lib/jenkins/.m2/repository/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-SNAPSHOT.pom 
[INFO] 
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ testproject --- 
Downloading: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/maven-metadata.xml 
Downloaded: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/maven-metadata.xml (1012 B at 28.2 KB/sec) 
Uploading: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.jar 
Uploaded: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.jar (47 KB at 748.5 KB/sec) 
Uploading: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.pom 
Uploaded: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.pom (6 KB at 149.3 KB/sec) 

質問がされている:私はのpom.xmlで指定されたバージョンを

を考えるとジェンキンスがにtestproject- 0.1-20120509.161644-74の.jarをアップロードする方法来る

<version>0.1-SNAPSHOT</version> 
  1. ですネクサス? 20120509.161644-74はどこから来ますか?タイムスタンプ20120509.161644から74は、アップロードする前に、ジェンキンスによって生成された場合

  2. は、私はそれの書式を設定することができますか? $ {タイムスタンプ} - - 私はtestproject-01のようなものが欲しい$ {} reversionId maven deploy plugin pageが伝え

答えて

8

の.jar「をそのアーティファクトのスナップショットのバージョンがリポジトリに配備されているデフォルトでは、、タイムスタンプはそれに接尾辞が付きます。 "したがって、mvn deployに電話すると、プラグインによって作成されます。

2)で希望するものが可能かどうかわかりません。私はそれが何か問題を引き起こすかもしれないと思う。

SNAPSHOT依存関係を持つmavenを使用する場合、タイムスタンプはSNAPSHOTの最新バージョンをチェックするために使用されます。スナップショットの形式を変更すると、このメカニズムが失敗する可能性があります。

+2

さらにもう1つ:これはあくまで3以降です。さらにいくつか[info](http://stackoverflow.com/questions/4275466/how-do-you-deal-with-maven-3-timestamped-スナップショットを効率的に) – Miquel

+0

私はこれが役に立つかもしれないと思う:http://maven.apache.org/plugins/maven-deploy-plugin/examples/disabling-timestamps-suffix.html –

+1

それが私の答えにこのリンクを投稿した理由です。 :-) – Behe

2

タイムスタンプは、Maven 3以降のSNAPSHOTバージョン内で追加されます。 Maven 2で実行された場合、同じデプロイメントプラグインはタイムスタンプを追加しません。

1

これはスナップショットのバージョンをロックダウンするMavenの方法です。特定のバージョンを別のビルドで使用することができます。これは問題を解決しますが、欠点があります。

私はスナップショットで家を回った。私は彼らが単に悪であると信じています。ビルドの再現性は、リポジトリにデプロイされたタイムスタンプ付きスナップショットのバージョンと特定のコードの提出を関連付けることが面倒なので頭痛です。

ビルドサーバーはビルド/デプロイメントの前にサーバーをビルドすることで、mvnバージョンを呼び出すことができます:set -DnewVersion = .. $ {build.number}。ソースコードに同じバージョンのタグを付けます。ビルドに失敗した場合でも問題はありません.pom.xmlファイルが変更されたときに作業領域をリフレッシュするようにビルドを設定することはできません。

スナップショットを使用する際の典型的なMavenの「落とし穴」は、ビルド中にpomが使用する可能性のあるバージョンの依存性を正確に把握できていないということです。他のmvnビルド引数。 (これは推移的な解決中に同じアーティファクトのバージョンの不一致を識別するのに役立ちます - 私は自分のビルドのDependencyManagementセクションで誓います)。

Mavenは非常に時間がかかりますが、「Maven Way」は必ずしも最適な解決策ではありません。 ではなく、が成熟しているため、Continuous Deliveryのベストプラクティスは成熟していますが、落とし穴に気づいていれば、効果的に作業することができます。

関連する問題