アーティファクトをArtifactoryにアップロードする方法/アーティファクトに拡張子がないビルドシステム（Gradle Maven Ant）で使用する方法
9.8.0バージョンのアーティファクトとしてArtifactoryにアップロードしたい次のファイルがあります。
[〜＃〜] note [〜＃〜]：最初の2つのファイルには拡張子がありません（これらは実行可能ファイルです。つまり、ファイル/ catを開くと、ジャンク文字が表示されます） 。
CVSの特定のバージョン9.8.0のフォルダー/ファイルは次のようなものです。
com.company.project/gigaproject/v9.8.0/linux/gigainstall com.company.project/gigaproject/v9.8.0/solaris/gigainstall com.company.project /gigaproject/v9.8.0/win32/gigainstall.exe com.company.project/gigaproject/v9.8.0/gigafile.dtd com.company.project/gigaproject/v9.8.0/gigaanotherfile .dtd com.company.project/gigaproject/v9.8.0/giga.jar com.company.project/gigaproject/v9.8.0/giga.war
拡張子が付いた上記のファイルのアップロードは非常に簡単です...アーティファクトをデプロイするためのアクセス権を持つ管理者/ユーザーとしてArtifactoryにログインし、[デプロイ]タブをクリックして、Artifactoryファイルを参照し、ファイルを選択したら、 「アップロード」ボタンをクリックしてください。
次に、画面が表示されます（上記のように）。このページのフィールドで必要なものを微調整し、[アーティファクトのデプロイ]をクリックすると完了です。アップロード中に正しいfile.extensionファイルを選択し、ファイル拡張子が[ターゲットパス]ボックスに正しく表示されていることを確認するだけです（バージョン-x.x.xなど）。
私の質問：
質問1：拡張子のないアーティファクトをアップロードするにはどうすればよいですか？ Artifactoryは、デフォルトでアーティファクトを.jar拡張子として使用しているようです。 LinuxとSolarisの両方で、上記のフォルダー/ファイル構造に示されている「gigainstall」アーティファクトをアップロードするにはどうすればよいですか？アーティファクト名をgigainstall-linuxおよびgigainstall-solarisとして使用して区別できるようですが、このアーティファクトに拡張子がないことをArtifactoryに伝える方法がわかりません。
開発チームが適切な拡張子でこのアーティファクトの生成を開始するとは思わない（このアーティファクトは、現在どこかでCVS/SVNソース管理から取得している他のプロジェクトのどこでもハードコーディングされている可能性があるため、それ自体は悪い習慣ですアーティファクトをソース管理バージョンツールに保存します）。
質問2：ビルドシステム（Gradleなど）に、たとえば「コンパイル」タスク中に拡張されていないアーティファクトを消費するように指示するにはどうすればよいですか？セクションの依存関係{..}の下のbuild.gradleに、以下に示すようなものを追加しますが、拡張されていないファイル（上記のフォルダー/ファイル構造の最初の2つ）についてはわかりません。
依存関係{
//コンパイル 'com.company.project：gigainstall-linux：9.8.0 @'
//コンパイル 'com.company.project：gigainstall-linux： 9.8.0 @ ?????? '
//コンパイル' com.company.project：gigainstall-linux：9.8.0 @ "" '
//コンパイル' com.company。 project：gigainstall-linux：9.8.0 @ "none" '
//コンパイル' com.company.project：gigainstall-linux：9.8.0 @ "NULL_or_something" '
//以下は、Artifactoryリポジトリからgiga.jarバージョンgiga-9.8.0.jarを簡単に取得します
コンパイル 'com.company.project：giga：9.8.0'
//以下は簡単にgiga.war
を取得します 'com.company.project：giga：9.8.0 @ war'
//同様に、他の拡張機能ベースのアーティファクトArtifactory
からフェッチできます。compile'com.company.project：gigafile：9.8.0@dtd '
compile'com.company.project：gigaanotherfile：9.8.0 @ dtd'
}
回答1（別の意味で2もカバーします）：[デプロイ]タブのアーティファクトリーの[アーティファクトバンドル]機能セクションを使用すると、トリックを実行できますfor AT最初にZipファイル（構造とアーティファクトを含む）を作成することにより、必要な方法でアーティファクトをアップロードする必要がありません-ORアップロードできますアーティファクトの使用/呼び出しアーティファクトREST API方法。
高レベルのアイデア：
Artifactoryが読み取ることができるgigaproject.Zip OR anyname.Zip/.tar/compressed fileという名前のZipファイルを作成します。Zip内に構造を作成します-これらのアーティファクトがArtifactoryにロードされる方法
つまり gigaproject.Zipには、次のフォルダー/構造/ファイルが含まれます。
ケース1：
com/company/project/gigaproject/9.8.0/linux/gigainstall com/company/project/gigaproject/9.8.0/solaris/gigainstall com/company/project /gigaproject/9.8.0/win32/gigainstall.exe com/company/project/gigaproject/9.8.0/gigafile.dtd com/company/project/gigaproject/9.8.0/gigaanotherfile .dtd com/company/project/gigaproject/9.8.0/giga.jar com/company/project/gigaproject/9.8.0/giga.war
[〜＃〜] note [〜＃〜]：ケース1の例では、ファイル名に-xxxを使用しませんでした（つまり、gigaの代わりにプレーンで単純なgiga.jarを使用しています） -9.8.0.jar）。
上記のアップロード/デプロイにより、ファイルが作成されます（次のスナップショットを参照）。
だから、私たちは私たちが望んでいたことを達成しました。実際には（明らかにそうですが）、Artifactoryは通常これらのアーティファクトを保存します（ファイル名に埋め込まれた-x.x.xバージョンであり、アーティファクトIDがアーティファクトファイル名と一致する必要があるため）。さて、Gradleビルドファイルで以下を使用したい場合は、最初はできません。-xxxバージョン名を含むファイル名をアップロードしていません。次に、ケース1ツリーのアーティファクトIDは「gigaproject」（ com/company/projectフォルダーの後）、したがって、どのアーティファクトIDとどのアーティファクトファイル名が必要かをGradleで定義する方法は機能しません。
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
結論：任意の構造のファイル（Artifactoryの拡張子の有無にかかわらず）をアップロードすることは可能ですが、ビルドシステムがそれをどのように消費するか、または消費できるかどうかによって異なります。 -ケース1の.Zipファイルで作成したばかりの構造をArtifactoryリポジトリから削除して、次のケース＃2を試し、作成した.Zipファイルを削除しました。
ケース2：
アーティファクトごとに個別のバージョン管理されたファイル名を作成し、Artifactoryが実際にそれらを格納する方法（ツリービューのリポジトリに表示されるアーティファクト）の形式で構造を作成し、その構造を含む.Zipファイルを作成しましょう。同じ「アーティファクトバンドル」機能を使用して、この.Zipファイルをアップロードし、Artifactoryで必要な個々のアーティファクトをアップロードしましょう。artifact-id（アーティファクトID（消費しようとしているときに言及する2番目の値）はArtifactoryのアーティファクトファイル名と一致します）。
.Zipファイルのフォルダー/ファイル構造：
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd com/company/project/giga/9.8.0/giga-9.8.0.jar com /company/project/giga/9.8.0/giga-9.8.0.war
[〜＃〜] note [〜＃〜]：今回は、同じ「アーティファクトバンドル」機能を使用し、同様のファイル（Linux/Solarisフォルダーの両方でgigainstall）を使用します。 gigainstallフォルダー（gigainstall-9.8.0.linuxおよびgigainstall-9.8.0.solarisファイル名を含む）を作成するアプローチ。つまり、コンパイルのために依存関係{...}セクションの下でGradleでこれらのアーティファクトを使用する場合。 xxx @の方法を使用して、Artifactoryからこれらのアーティファクトをフェッチします。
OK、「アーティファクトバンドル」のデプロイ/アップロードが正常に完了すると、次のメッセージが表示されます。
アーカイブから7つのアーティファクトを正常にデプロイしました：gigaproject.Zip（1秒）。
それでは、アーティファクトの1つを検索している間、またはツリービューで、Artifactoryでどのように表示されるかを見てみましょう。 Gradleで簡単に使用できるように、filename-x.x.x.extensionの方法でファイルが配置されていることがわかります。
Gradleビルドファイル（build.gradle）で、私は言及します：
依存関係{
コンパイル "com.company.project：gigainstall：9.8.0@linux"
コンパイル "com.company.project：gigainstall：9.8.0@solaris"
コンパイル "com.company.project：gigainstall：9.8.0@linux"
コンパイル "com.company.project：giga：9.8.0
コンパイル" com.company.project ：giga：9.8.0 @ war
compile "com.company.project：gigafile：9.8.0 @ dtd
compile" com.company.project：gigaanotherfile：9.8.0@dtd
}
OH OH !!-それは機能しませんでした。Gradleエラーについては以下を参照してください。どうして？ -アーティファクトバンドルのアップロード/デプロイ機能は、.ZipにあるものをZipファイルコンテンツにアップロードしますが、デプロイするアーティファクトごとに.pomファイルを作成しません。したがって、Gradleビルドを失敗させます。 Antにいる可能性があり、これは成功する可能性があります。これは、個々の.jar/.war/.dtd/etcファイルごとに発生しました。エラーの例を1つだけ示しています。
実行中gradle clean build
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve com.company.project:gigafile:0.0.0.
Required by:
com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0
> Could not GET 'http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom'. Received status code 409 from server: Conflict
ケース：簡単なアプローチを取りましょう（回避策ですが、多くの苦痛を軽減します）。次の構造でgigaproject.Zipファイルを作成します。このアプローチでは次のようになります。フォルダ/ファイル構造内の個々のアーティファクト/ファイル名にx.x.xバージョン値が埋め込まれていません。 「シングルアーティファクト」アプローチを使用します（Artifactoryが提供するアップロード/デプロイプロセス中にgigaproject.Zipファイルの.pomを自動的に作成します）。このアプローチを使用すると、名前の拡張子を必要とせずにgigainstallファイルを取得できます。アップロード/デプロイのステップで、すでに見てきたように、gigaproject.Zipをアップロードすると、アーティファクトはそれを「gigaproject-xxx。Zip」として特定のターゲットリポジトリにアップロードします。ここでxxxは、この場合9.8.0です。以下の画像スナップショットを参照してください。
gigaproject/linux/gigainstall gigaproject/solaris/gigainstall gigaproject/win32/gigainstall.exe gigaproject/gigafile.dtd gigaproject/gigaanotherfile .dtd gigaproject/gigaproject.Zip gigaproject/giga.jar gigaproject/giga.war
次に、「単一アーティファクト」機能を使用してアーティファクトリーにアップロードします。 GroupId、ArtifactId、Versionなどの値を微調整したら、[DeployArtifact]をクリックします。
これがアップロードされたら。ターゲットリポジトリのZipアーティファクトに表示されます（悪い例を取り上げました。通常、これはext -...ではなくlibs-snapshot-localまたはlibs-release-localになります）、消費できるようになりますGraddleで直接Zipアーティファクト：
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0@Zip"
}
.ZipがGradleビルドシステムで利用可能になったら、実際の（解凍された）ファイル（gigainstall、.dtd、.jar、.war）をフィードできるビルド/ワークスペース領域のどこかにこの.Zipファイルを解凍するようにGradleに指示できます。 、など）ビルドプロセス/ステップに。
[〜＃〜] ps [〜＃〜]：ケース＃1と2はAntで機能したと思います。
回答2：いずれかの方法で拡張されていないファイルをアップロードした場合。 POMファイルも手動で作成/アップロードしたことを確認してください（つまり、com/company/project/gigainstall/9.8.0 /gigainstall-9.8の下にアーティファクトとしてgigainstall-9.8.0をアップロードした場合。 0、同じレベルで、POMファイルを作成する必要があります（カスタムjarアーティファクトの単純なテンプレート.pomファイルを参照するか、「シングルアーティファクト」デプロイを介して拡張ファイルをアップロードするときに、 POMエディターウィンドウに表示される内容を確認し、両方をアップロードして、GradleがPOMの競合/エラーがないとエラーを出さないようにします。Antはpomを必要としない可能性があります（チェックしませんでした）それ）。
Artifactoryにあると、次の行が機能するはずです-OR別の方法を見つけたら、コメントしてください。
dependencies {
// See nothing mentioned after - x.x.x@
compile "com.company.package:gigainstall:9.8.0@"
}