問題タブ [nexus]

企業のネクサスリポジトリを開発者にリリースする予定です。手元にある問題は、リポジトリからダウンロードできるjarのバージョンに標準を適用したいということです。たとえば、Spring Frameworkバージョン3が組織の標準としてnexusですでに利用可能である場合、開発者は、テクニカルアーキテクトによって承認されない限り、nexusを使用してSpringの最新バージョン（3.3など）をダウンロードできません。

開発者は中央を直接ポイントしてjarをダウンロードできるため、これを行う方法はないと言えます。ただし、このシナリオは、nexusのjarのみを使用する毎日のhudsonCIビルドで処理されます。

私たちの最初の提案は、合意されたバージョンのライブラリを使用してネクサスを設定し、次にネクサスプロキシ設定を変更して中央に到達できないようにすることでした。これより良いアイデアはありますか？

I'm currently using Nexus as an artifact repository manager. Artifacts are deployed to Nexus automatically via a build machine running Hudson. The build machine is a 64 bit whereas my development machine is 32 bit.

I would like to create a 32 bit build slave which would automatically build a 32 bit version of our code (e.g. code which uses JNI). Is there a way for Nexus to store both 32bit and 64bit artifacts?

At the moment it seems to me that the "last build wins" e.g. if I build a snapshot project on a 32 bit machine and then a 64 bit machine, the 64 bit version of the artifact is what projects try to download.

ディレクトリ全体とその中のすべてのサブディレクトリを Nexus リポジトリ サーバーとの間でアップロード/ダウンロードすることは可能ですか?

ローカルの Nexus Maven リポジトリに一連のアーティファクトを追加しました。
プロジェクトをビルドすると、次のエラーが発生します。

[情報] プロジェクトをスキャンしています...
[情報] -------------------------------------- ----------------------------------
[INFO] pronto-web Java EE 6 Webappの構築
[INFO] task-セグメント: [検証]
[情報] ------------------------------------------ ------------------------------
[INFO] [resources:resources {execution: default-resources}]
[WARNING] プラットフォームの使用エンコーディング (実際には Cp1252) を使用して、フィルタリングされたリソースをコピーします。つまり、ビルドはプラットフォームに依存します!
[INFO] 4 つのリソースをコピーしてい
ます [INFO] [compiler:compile {execution: default-compile}]
[WARNING] ファイル エンコーディングが設定されていません。プラットフォーム エンコーディング Cp1252 を使用しています。つまり、ビルドはプラットフォームに依存します!
[情報] 1 つのソース ファイルを C:\Source\Pronto\pronto\pronto-web\target\classes にコンパイルしています
[情報] [antrun:run {execution: remove-javax}]
[情報] タスクの実行
[情報] 実行されたタスク
[ INFO] [gwt:compile {execution: default}]
[INFO] using GWT jars from project dependencies : 20100714-SNAPSHOT
[警告] gwt-dev をプロジェクトの依存関係として宣言しないでください。これにより、複雑な依存関係の競合が発生する可能性があり
ますwindows.jar
[情報] ------------------------------------------------ ----------------------------
[エラー] ビルド エラー
[情報] - - - - - - - - - - - - - - - - - - - - - - - - -------------------------
[情報] アーティファクトが見つかりません - リポジトリでリソースが見つかりません

プロジェクトの Web サイトからファイルを手動でダウンロードしてみてください。

次に、次のコマンドを使用してインストールします:
mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-dev -Dversion=20100714-20100715.053026-1 -Dclassifier=windows -Dpackaging=jar -Dfile=/path/ファイルへ

または、独自のリポジトリをホストする場合は、そこにファイルをデプロイできます:
mvn deploy:deploy-file -DgroupId=com.google.gwt -DartifactId=gwt-dev >-Dversion=20100714-20100715.053026-1 -Dclassifier=windows -Dpackaging =jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

com.google.gwt:gwt-dev:jar:20100714-20100715.053026-1

指定されたリモート リポジトリから:
リリース ( http://mercury:8980/nexus/content/groups/public )、
すべて ( http://mercury:8980/nexus/content/groups/all )、
スナップショット ( http ://mercury:8980/nexus/content/groups/all )水銀: 8980/nexus/content/groups/public-snapshots )

http://mercury:8980/nexus/content/groups/public-snapshots/com/google/gwt/gwt-dev/20100714-SNAPSHOT/gwt-dev-20100714-20100715.053026-1-windows.jar
[情報] -- -------------------------------------------------- --------------------
[情報] 詳細については、-e スイッチを指定して Maven を実行してください
[情報] ------------- -------------------------------------------------- ---------
[INFO] 合計時間: 8 秒
[INFO] 終了時刻: Thu Jul 15 08:57:29 CEST 2010
[INFO] Final Memory: 50M/614M
[INFO] ----- -------------------------------------------------- -----------------

アーティファクト名に「-windows」を追加する必要があるとmavenが考える理由を誰か知っていますか? (ダウンロード: http://mercury:8980/nexus/content/groups/public-snapshots/com/google/gwt/gwt-dev/20100714-SNAPSHOT/gwt-dev-20100714-20100715.053026-1-windows.jar)

リポジトリを参照すると、アーティファクトが含まれていますが、「-windows」サフィックスはありません。

このアーティファクトの古いバージョンはプラットフォームに依存し、分類子として「windows」または「linux」または「mac」を持っていましたが、最近のバージョンはプラットフォームに依存せず、poms にそのような分類子はありません。

PS: リンクを投稿するのに十分な評判がまだ得られていないため、各 URL のプロトコルとコロンの間にスペースを追加しました。

私は自分のプロジェクトのいくつかをオープンソース化しました。アーティファクトを共通の場所に公開したいと思います。自分のリポジトリをホストする必要がない場合は、それが理想的です。そうでない場合は、Nexusの自分のインスタンス（または推奨する他のリポジトリ）をセットアップする必要があります。

アーティファクトをMavenCentralに公開できますか？それらをそこに到達させるためにどのようなプロセスに従う必要がありますか？

多くの (約 50 以上の) maven2 プロジェクトを整理して、中央の nexus リポジトリにデプロイできるようにする方法を見つけようとしています。目標を使用する場合、mvn deploy次のように distributionManagement タグでターゲットを指定する必要があります。

ここで、すべての pom.xml (50 以上) にこのブロックを何度も含める必要はありません。私の最初のファイルはsettings.xmlファイルですが、（設計上）そこに定義することはできないようです。では、最初の質問は、なぜそうなのかということです。可能であれば、すべての開発者に配布できる maven2 ディストリビューションの settings.xml で指定できます。

私が見つけた唯一の可能な解決策は、これらの設定を含む組織全体の master-pom プロジェクトを作成し、他のすべての pom.xml を<parent>タグを介してこの master-pom に依存させることでした。しかし、これはマルチモジュール ビルドでは奇妙に見えます。

通常、私はすべてのドキュメントで、モジュール poms が別のものではなく、親 pom を使用する必要があることを読みました。しかし、継承対集約に関するMaven Webサイトを読んだ後、それは実際に可能であると書かれています。

私が見つけた問題の 1 つは、Maven サイトの生成に関するものでした。これは、このセットアップに問題があるようです (直接の後方参照がない場合、モジュールは正しくリンクされません)。

それで、これは有効なアプローチですか？問題に対する他のより明白で簡単な解決策はありますか?

Nexus OSS を社内リポジトリとして展開中です。主な要件の 1 つは、jar が Nexus によってダウンロードされると (たとえば、Maven Central のプロキシとして使用する場合)、決して変更されないことです。Maven Central にそのポリシーがあることは知っていますが、自分の管理下にない他のリポジトリを使用しているため、自分の側でその要件を検証する必要があります。

リリース リポジトリ ポリシーは、jar がそのリポジトリにダウンロードされると変更されないことを保証しますか?

1.5 年前に作成された製品のバージョンに戻ることができるようにするための要件が​​存在し、製品で使用されるリポジトリ アーティファクトが現在ビルドするときに同じであることを確認します。

ソフトウェアを保持するNexusリポジトリがあります（驚き...）。私たちの IDE では、リポジトリを追加して、視覚的にナビゲートできるようにしました。

問題: IDE は、現在毎晩更新される .index フォルダー (gz ファイルを含む) を使用します。

私が望むのは、誰かがアーティファクトを追加すると、.index が自動的に更新されることです。それは可能ですか？

私が望んでいないのは、インデックス自体を数分ごとに更新することです。

Leiningen を使用して Clojure プロジェクトを作成しましたが、結果の jar を Sonatype Nexus サーバーに追加したいと考えています。これには、Clojars 以外の場所にプッシュしたい場合にpushオプションの引数を受け入れるように見えるコマンドが付属しているため、lein-clojars をインストールしました。repoただし、これを試すたびに、JSchException: Auth fail. どこかに認証の問題があることを示しているようです。

jar を Nexus に scp することができます。また、Maven で同じ settings.xml を使用してこのマシンにアップロードすることもできるので、これらはどちらも正しいと確信しています。

Leiningen を使用して他のリポジトリにプッシュする良い方法はありますか? それとも、本当にClojars専用に構築されているのでしょうか?

Hudson（1.368）でMavenのリリースプラグインを使用すると、NexusMavenリポジトリマネージャーへのデプロイフェーズ中にdistributionManagementセクションが欠落しているというエラーが発生します。リリースを使用せずにデプロイした場合は問題なく動作するため、サーバー、セクション、または設定の構成を誤ってはいけません。

私の会社がハドソンに異なるpomファイルを使用し、それらに異なる名前を付けていることは注目に値します。また、個々のプロジェクトディレクトリにあるsettings.xml。Hudsonではpomの名前と、設定ファイルの場所と名前を指定できるため、これが問題になることはありません。

上記に注意する理由は、distributionManagementを通常のpom.xmlに移動すると、それが検出されるためです（ただし、設定ファイルにユーザー名とパスワードがないため、機能しません）。これは、リリースプロセスの前の部分で、正しいpomと設定を使用するため、私を混乱させます。後でそれらを忘れているようです。ここで何が起こっているのですか？

前もって感謝します。

更新
mavenリリースプラグインは、別の名前のpomではなくデフォルトのpom.xmlを使用しているmavenの新しいインスタンスを起動するようです。より多くのテストが必要です。