問題タブ [artifactory]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
maven - Mavenが「MyRepoの更新間隔が経過するまで解決は再試行されません」と言った場合、その間隔はどこに指定されていますか?
Maven を使用すると、まだビルドしていない、またはまだリポジトリに含めていないサードパーティのリポジトリからのアーティファクトにヒットすることがあります。
Maven クライアントから、アーティファクトが見つからないというエラー メッセージが表示されます。
[
http://myrepo:80/artifactory/repo
_ヘルプ1]
今、私はこれが何を意味するのかを理解し、 でコマンドを再実行するだけで-U
、通常はそこから正常に動作します。
しかし、このエラー メッセージは非常に直感的ではないことがわかり、同僚の頭を悩ませないようにしています。
update interval
この設定 を変更できる場所があるかどうかを調べようとしています。
- このエラー メッセージに記載されているのは
update interval
、クライアント側またはサーバー側の設定ですか? - クライアント側の場合、どのように構成しますか?
- サーバー側の場合、Nexus/Artifactoryがこれらの設定を公開する方法/場合を知っている人はいますか?
maven - IntelliJ Ideaで使用するための、パスワードなしの無料のアーティファクトまたはネクサスサービスのURL
Intelliji Ideaには、設定->maven->アーティファクトまたはネクサスサービスのURLに3つの無料オンラインリポジトリが付属しています http://oss.sonatype.org/service/local/http://repo.jfrog.org/artifactory/api/ https : //repository.jboss.org/nexus/service/local/
このリポジトリはすべて利用できません(404エラーまたはパスワードで保護されています)。
パスワード保護なしで、より多くの無料のアーティファクトまたはネクサスサービスのURLを提供できますか?IDEAには、リポジトリURLのパスワードの設定がありません。
java - Hudson プラグインがすべてのアーティファクトを Artifactory に公開しない
Hudson サーバーを介して継続的にビルドする小さな Java プロジェクトのセットアップがあります。ビルド アーティファクトをビルド後のステップとして Artifactory サーバーに公開したいので、当然、これを容易にするために Hudson-Artifactory プラグインを使用しています。ローカル パブリッシュは問題なく動作しているように見えます。2 つのアーティファクト (両方の .jar ファイル) と解決済みの ivy.xml ファイルが期待どおりにパブリッシュされます。しかし、Hudson サーバーでビルドを要求すると、2 つのアーティファクトのうち 1 つだけが公開されます。
ビルドにより、次のアーティファクトが作成されます。
私の ivy.xml ファイルは次のようになります。
この 2 つのアーティファクトは、この<publications>
セクションで明確に示されています。私の build.xml ファイルのビルド ターゲットは次のようになります。
ビルド ディレクトリからすべてのartifactspattern
定義済みアーティファクトを取得します。最後に、私の ivysettings.xml ファイルのリゾルバー チェーンは次のようになります (無害な人を保護するためにサーバー名が変更されています)。
それはすべてかなり日常的なものであり、前述のように、ローカル パブリッシュは正常に機能します。Eclipse でビルドしたときのコンソール出力を次に示します。
.jar ファイルと解決済みの ivy.xml ファイルの両方が期待どおりに公開されます。私の Hudson サーバーでは、次のように Artifactory 構成設定を構成しました (ここでも、私の真のスーパーヒーローのアイデンティティを曖昧にするためにいくつかの詳細が変更されています)。
Artifactory サーバー: http://my.server.employer.com:8080/artifactory
ターゲット リポジトリ: target-repository
Ivy パターン: [organisation]/[module]/[revision]ivy-[revision].xml
Artifact パターン: "[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
ご覧のとおり、Ivy と Artifact のパターンは、ivysettings.xml ファイルのローカル リゾルバーのパターンとまったく同じです。したがって、Hudson サーバーでビルドを実行すると、まったく同じアーティファクトが Artifactory サーバーに公開されることが期待されます。
Hudson サーバーの最新のビルドからのコンソール出力を見てみましょう。
ドゥビャ'ティーエフ!? ここでも、ローカル パブリッシュは正常に機能しているように見え、jar ファイルと ivy.xml ファイルの両方が Hudson サーバーの local/esf/ftpSvc/SNAPSHOT/ ディレクトリにパブリッシュされます。一方、Artifactory プラグインはすべてが完全に間違っています。2 つの jar の 1 つを公開できないだけでなく、ivy.xml ファイルの名前を誤って変更します。
ここで何が起こっているのかを解明できる Hudson/Ivy/Artifactory の専門家はいますか? まったく同じ動作を示しているプロジェクトが複数あります。この問題を解決するためのすべての支援をいただければ幸いです。
maven-2 - Artifactory のアーティファクトをリモート リポジトリにコピーする
私は次の設定をしています:
- Hudson、Maven、および Artifactory を稼働させて継続的にビルドするための開発サーバー。
- Maven でアーティファクトを構築し、Hudson にそれを Artifactory にデプロイさせることができます。
ただし、次のことを行いたいと思います。
- ローカル ビルド サーバーの Artifactory でアーティファクトを選択します。
- 新しいビルドを行わずに、そのアーティファクトをリモート リポジトリにデプロイします。
私がそうしたい理由は、最初のサーバーが、新しいアーティファクトが自由に変更される開発サーバーであるためです。他のサーバー/リポジトリは、会社のすべてのアーティファクトの公開サーバーです。
2 番目のビルド ジョブを作成できることはわかっていますが、それは重複することになり、Hudson は一度に 1 つの Artifactory リポジトリしか管理できません。そのアーティファクトを手動で別の URL にデプロイすることもできますが、これはエラー プルーンであり、ビルド サーバーにログインする必要があり、それを行うにはシェルを使用する必要があります。
最終的に目標に到達する方法を知っている人はいますか?
hudson - Jenkins/HudsonのArtifactoryプラグインと一緒にIvyプラグインを使用する
Ivyプラグイン( http://wiki.jenkins-ci.org/display/JENKINS/Ivy+Plugin)とArtifactoryプラグイン( http://wiki.jenkins-ci.org/display/JENKINS/ )を使用しようとしています。 Artifactory + Plugin)。
私は次の例外を取得しています:
このバグレポートによると、https://issues.jfrog.org/jira/browse/HAP-65、
プラグインは意図的に外部のツタの構成設定に依存しています
しかし、この外部構成を行う方法をどこにも見つけることができません。どんな助けでもいただければ幸いです。
java - SNAPSHOT修飾子をあきらめずにアーティファクトのトレーサビリティが必要
バックグラウンド。私の組織は、Maven、Bamboo、Artifactoryを使用して、継続的インテグレーションプロセスをサポートしています。Artifactoryでのストレージの管理(古いSNAPSHOTビルドのローテーション)とチーム間の統合の最新化(MavenはビルドごとにSNAPSHOTの依存関係の更新を自動的にチェックする)を支援するために、MavenのSNAPSHOT修飾子に依存しています。
問題。私たちが抱えている課題の1つは、SNAPSHOTを使い続けながら、環境から環境へのビルドを正しく促進することです。テスターがバージョン1.8.2-SNAPSHOTを機能テスト環境にデプロイし、Subversionのリビジョン1400にあるとします。また、機能テストに合格したとしましょう。テスターがArtifactoryからパフォーマンステスト環境に1.8.2-SNAPSHOTをプルすることを決定するまでに、開発者はSubversionへの変更をコミットできた可能性があるため、Artifactoryの実際のバイナリは異なる回転数になります。SNAPSHOTビルドを使用するときに、回転数が下から変わらないようにするにはどうすればよいですか?
制約。明らかに、無意識のうちに異なるビルドをデプロイしたくありません。また、機能テストでテストしたパフォーマンステストで正確なバイナリをテストしたいので、ソースから再構築したくありません。
私たちが検討したアプローチ。考えは、バージョンに1.8.2.1400のような4番目のコンポーネントをスタンプしたいということです。ここで、4番目のコンポーネントはSubversionrevです。(副次的な質問として、Mavenプラグインまたはそれを自動的に行う他の何かがありますか?)しかし、そうすると、MavenとArtifactoryはこれらが異なるバージョンであると考えるため、本質的にスナップショット機能が失われます。
スクラムを使用しているため、非常に早い段階(2日目程度など)でテスト環境にデプロイします。SNAPSHOTのメリットが再び失われるため、開発サイクルの早い段階でSNAPSHOT修飾子を削除することは意味がないと思います。
他の組織がこの問題をどのように解決するかを知っていただければ幸いです。
java - Artifactory 用の内部 pom.xml を使用してプレーン jar を maven jar にする
ant で生成された xyz.jar を使用する必要があります。したがって、推移的な依存関係がありません。そこで、xyz.jar を変更して、内部 META-INF/maven/groupId/artifactId/pom.xml および pom.properties ファイルを追加するという考えがありました。
Artifactory にデプロイすると、それらは無視され、依存関係のない独自の pom.xml が生成されました。
Artifactory は、xyz.jar ファイルと同じフォルダーにある pom.xml をデプロイします。
すでにこれであまりにも多くの時間を失いました...
maven-3 - プロジェクトとプラグインの依存アーティファクトの保存を分離する最良の方法
Maven 3 では、プロジェクトとプラグインの依存アーティファクトを分離できます。
リポジトリをプロキシしてホストしている場合、リポジトリ マネージャー (nexus ...) でこれを行う最善の方法は何ですか? これを settings.xml/pom.xml で定義する例はありますか?
プラグインとプロジェクトの依存関係のために、プロキシされたすべてのリポジトリを複製する必要がありますか?
maven - 内部リポジトリを初めて設定するときに、ローカルの Maven リポジトリを内部リポジトリに移動できますか?
実際にMavenを使用し、さまざまなビルド中にローカルリポジトリにデータを入力した後、アーティファクトを内部リポジトリとしてセットアップしたかったのです。自分のマシンにアーティファクトをセットアップする前に、ローカル リポジトリは既にさまざまなライブラリをローカル マシンの .m2 にダウンロードしています。現在、Artifactory を使用して内部リポジトリをセットアップしています。.m2 の下のローカル リポジトリをアーティファクトに移動する簡単な方法はありますか?
現在、私がしなければならないことは、ローカルリポジトリ (.m2\repository) の下にあるすべてのフォルダーを削除してから、maven ビルドをアーティファクトにダウンロードできるようにすることです。これを行うためのより効率的な方法を探しています。
maven - 以前にデプロイされたアーティファクトが上書きされないようにするにはどうすればよいですか?
当社の Maven リポジトリには Artifactory を使用しています。同じバージョン番号の既存のアーティファクトがある場合にアーティファクトをリポジトリにデプロイできないように設定 (または Maven を設定) する方法はありますか?
これは、有効なリリースが誤って上書きされないようにするためです。アーティファクトを本当に再デプロイする必要がある場合は、開発者の 1 人が Artifactory Web インターフェイスを使用してそれを削除できます。その後、新しいコピーをデプロイできます。
ありがとう!