問題タブ [maven-central]

SBT ビルドを本番環境で使用するのに十分な信頼性を持たせるにはどうすればよいですか?

具体的には、SBT は通常問題なくビルドされますが、数週間おきにcommons-imagingの依存関係が見つからず、ビルド全体が停止します。

build.sbt で:

sbt.ResolveException: 未解決の依存関係: org.apache.commons#commons-imaging;1.0-SNAPSHOT: 見つかりません

これは通常うまくいきます。しかし、最近与え始めました：

(1) なぜこんなに断続的になるのですか? 変更されるのはリゾルバーの URL ですか、それともコモンズ イメージング jar を提供する Web サイトがダウンするのでしょうか? (他の Maven リソースは問題なく見つかります。)

(2) クリーン ビルドが常に成功するようにするにはどうすればよいですか? (これは、新しいインスタンスをスピンアップし、それが成功することを期待するために重要です。)

編集:これは質問には答えませんが、「withSources()」を削除するとビルドが成功するというこの特定の問題の回避策を見つけました。

Nexus OSS 3 Artifact Repository をバックアップおよび復元する標準的な方法があるかどうか疑問に思っていました。

「データ」ディレクトリをバックアップして、実行中の新しいインスタンスにコピーするだけで十分ですか?

Maven、NPM、Docker など、さまざまな種類のリポジトリを使用しています。

最終的にGradleに適したレポ（Artifactory）に公開するジャーのセットを「スニーカーネット」にしましたが、当分の間、マシン上でローカルにとどまる必要があります。

これらのjarをGradleプロジェクトで使用する必要があります.Gradleプロジェクトは、これらをリストできるようにするだけでなくdependencies、Eclipseプラグインを使用してEclipse IDE内の依存関係を解決します。

これらの jar にはすべて POM があり、独自の推移的な依存関係があります (これらはすべて、Maven Central や JCenter などの典型的なリポジトリにあります)。

これらのjarをファイルシステムのどこかに保存する方法を探していますがdependencies、推移的な依存関係の解決を含め、通常のように解決し、これと互換性を持たせる方法を探していますが、Gradle Eclipseプラグインはフードの下で動作します。

繰り返しますが、望ましい結果は次のようになります。

• これらの jar を依存関係として追加します。たとえば、~/special-jars/*
• 各「特別なjarの」POMで定義されている依存関係が何であれ、それらを解決します
• を実行するgradle eclipseと、Gradle はファイル システムからもそれらを取り込みます

これは可能ですか？もしそうなら、どのように？

少し前に、新しい maven パッケージをリリースしましたが、誤って雇用主の会社を<organization>に追加してしまいましpom.xmlた。可能であれば、これらのパッケージを交換するように依頼されました。

ステージング リリースは削除できます。ドキュメントには、リリースを削除するプロセスについては言及されていません。サポート チケットを送信する前に、これを行う公式の方法はありますか? それは可能ですか？

私たちの組織は隔離されたネットワークで作業しているため、ライブラリを使用する場合は、ライブラリを maven-central から取得し、独自の Maven リポジトリにアップロードする必要があります。

必要な依存関係のすべてのファイルをダウンロードする方法を探していgradle eclipseClasspathます。これを行うためにgradleを使用しましたが、すべてのファイルをダウンロードしていません。たとえばorg.jacoco:jacoco:0.7.8、zip ファイルが含まれていて、中をGRADLE_USER_HOME調べても zip が見つかりません。

build.gradle:

私は何をすべきか？

明確にするために、Android ライブラリ モジュールをJCenterorに公開してMaven Central、Android 開発者が私のライブラリを使用したい場合compile 'a.b.c'に、import module. もちろん、私はgradleライブラリモジュールについて話しています。

ただし、悪いニュースは、私のプロジェクトが、他のいくつかの会社の jar であるクローズソース ライブラリに依存していることです。したがって、ソースに近い jar を使用してモジュールを公開することが合法かどうかはわかりません。

それが公開ソースの中央法文書に依存するのか、それとも会社法文書に依存するのかについては明確ではありません。

Amazon ec2 インスタンスのジェンキンで実行される Maven ビルドがあります。ビルド全体には 20 ～ 30 分かかり、Maven Central からアーティファクトをダウンロードできないため、ほぼすべての実行が失敗します。これは、ログの失敗部分です。

興味深いことに、Maven Central と私たち自身のリポジトリからの 20 分間のダウンロードでは問題なく動作しますが、まったく同じダウンロードで 1 回おきに失敗します。これは、他のダウンロードでランダムに失敗するため、接続の問題が原因ではないと思います。

グーグルで調べたところ、IPv4 と IPv6 の問題が原因である可能性があることがわかったので、ビルドで java.net.prefetIPv4stack=true を設定しようとしましたが、役に立ちませんでした。

mvn を実行するコマンドは次のとおりです。

また、MAVEN_OPTS と JAVA_OPTS の両方で -Xmx を増やそうとしましたが (maven がすべての依存関係を RAM に保持できるようにする必要があることをどこかで読みましたが、真かどうかはわかりません)、成功しませんでした。

私が試すことができる他のアイデアはありますか？

編集：スタックトレースを追加

ネクサス バージョン 3.1.0-04

ビルド中に、Nexus からアーティファクトをダウンロードすると、次のエラーが表示されます。

ダウンロード > http://10.148.254.17:8081/nexus/content/repositories/central/org/assertj/assertj-core/2.4.1/assertj-core-2.4.1.jar :collection:extractIncludeTestProto FAILED

FAILURE: ビルドは例外で失敗しました。

• 問題: 構成 ':collection:testCompile' のすべての依存関係を解決できませんでした。assertj-core.jar をダウンロードできませんでした (org.assertj:assertj-core:2.4.1) リソースを取得できませんでした ' http://xxx.xxx.xxx.xxx:8081/nexus/content/repositories/central/org/ assertj/assertj-core/2.4.1/assertj-core-2.4.1.jar '. Content-Length で区切られたメッセージ本文の途中終了 (予想: 900718; 受信: 6862)

これは、Nexus に保存された大きなファイルに問題があるようです。

wget または curl でファイルをダウンロードしようとすると、失敗します。

c:> wget http://xxx.xxx.xxx.xxx:8081/nexus/content/repositories/central/org/assertj/assertj-core/2.5.0/assertj-core-2.5.0.jar

--13:57:06-- > http://xxx.xxx.xxx.xxx:8081/nexus/content/repositories/central/org/assertj/assertj-core/2.5.0/assertj-core-2.5. 0.jar => `assertj-core-2.5.0.jar' proxy.xxxx.com を解決中... 完了。proxy.xxxx.com[xxx.xxx.xxx.xxx]:xxx に接続しています... 接続しました。プロキシ要求が送信され、応答を待っています... 200 OK 長さ: 934,446 [アプリケーション/Java アーカイブ]

0% [ ] 6,856 1.44K/s ETA 10:27

13:57:21 (1.44 KB/秒) - バイト 6856 で接続が閉じられました。再試行しています。

c:>curl -O http://xxx.xxx.xxx.xxx:8081/nexus/content/repositories/central/org/assertj/assertj-core/2.5.0/assertj-core-2.5.0.jar

% Total % Received % Xferd Average Speed Time Time Time 現在の Dload Upload Total Spent Left Speed 0 912k 0 6862 0 0 613 0 0:25:24 0:00:11 0:25:13 613 curl: (18) transfer closed with残り 927584 バイトの読み取り

理由はありますか？