7

groovy で Gradle プラグインを作成し、Gradle を使用してビルドしました。Gradle Artifactory プラグインと Gradle の maven-publish プラグインを使用して結果を公開するローカル ネットワーク Artifactory サーバーがあります。依存関係としてこのプラグインに依存する別の Gradle ビルド スクリプトがあります。特定のバージョンで依存関係をリストすると、これをすべて機能させることができました。Maven のバージョン範囲 (例: '[1.0,2.0)') を使用しようとしましたが、maven-metadata.xml が見つからないと言って失敗します。Artifactory を確認しましたが、案の定、そこにはありません。できればプラグインのビルド中に、それを生成するために何をする必要がありますか?

カスタム gradle プラグインの build.gradle ファイルは次のとおりです。

buildscript {
    repositories {
        maven {
            url "${artifactory_contextUrl}/plugins-release"
            credentials {
                username = "${artifactory_user}"
                password = "${artifactory_password}"
            }
        }
    }
    dependencies {
        classpath group: 'org.apache.directory.studio', name: 'org.apache.commons.io', version: '2.4'
        classpath group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.0.9'
    }
}

plugins {
    id 'com.jfrog.artifactory' version '3.0.1'
}

apply plugin: 'groovy'
apply plugin: 'maven-publish'

artifactory {
    contextUrl = "${artifactory_contextUrl}"
    publish {
        repository {
            repoKey = 'plugins-snapshot-local'
            username = "${artifactory_user}"
            password = "${artifactory_password}"
            maven = true
        }
        defaults {
            publications ('mavenJava')
        }
    }
    resolve {
        repository {
            repoKey = 'libs-release'
            username = "${artifactory_user}"
            password = "${artifactory_password}"
            maven = true
        }
    }
}

dependencies {
    compile gradleApi()
    compile localGroovy()
}

publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
}

Gradle、Artifactory、および Maven のドキュメントを検索して、maven-metadata.xml と、生成およびデプロイの方法を理解しました。それが何であるかは理にかなっており、おそらく手動で構築することもできますが、maven-publish プラグインまたは artifactory-gradle-plugin を使用して Gradle で自動的に生成する方法を具体的に説明するものは見つかりません。ファイルを手動で更新する必要はありません。自動化の取り組みが無効になるためです。また、すでに Gradle に多くの投資を行っているため、mvn に切り替えたくありません。

4

4 に答える 4

0

maven-metadata.xmlArtifactory で処理する必要があります。Artifactory でのローカル リポジトリのレイアウトは?

于 2015-03-03T01:39:31.617 に答える
0

受け入れられた答えは正しいです。そして、私はそれを支持しました。ただし、この注意点もあります。

マルチモジュール プロジェクトがあるので、「allprojects」を使用します。monolith/single-jar ( :( ).. を使用している場合は、「allprojects」とは異なるスコープを使用できます。

ここで重要なのは、「グループ」を設定することです。（バージョンも）

すべてのプロジェクト {

apply plugin: 'java-library'
apply plugin: 'maven-publish'
apply plugin: 'com.jfrog.artifactory'


repositories {
    jcenter()
}

group = 'com.group'

version = '1.0-SNAPSHOT'

}

さて、build.gradle (私のマルチモジュール プロジェクトでは root-build.gradle ではありません) (ただし、ルート build.gradle の値は似ています)

以下は、ルート以外のbuild.gradleファイルの内容全体です

// the "name" variable inside the publications/myPublicationName block is getting overwritten.  so create a variable here to capture the name (as the artifactid)
def artifactIdForPublicationBlockHolder = "${name}"


dependencies {
    testImplementation group: 'junit', name: 'junit', version: junitVersion
}

println("hey.here.read.me")
println("group=${group}")
println("version=${version}")
println("artifactId=${name}")


publishing {
    publications {
        myCustomPublicationName(MavenPublication) {
            // groupId, artifactId and version have defaults, so do not arbitrarily override : https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:publications

//your value below could be slightly different, look for *.jar after you do ./gradlew. build (note, this path value (of "./") is relative to the non-root-build.gradle path, not the overall root-build.gradle
"./build/libs/${artifactIdForPublicationBlockHolder}-${version}.jar"
        }
    }
}

リンクが示すように、デフォルトを取得します

// groupId、artifactId、version にはデフォルトがあるため、勝手に上書きしないでください: https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:publications

上記のように、これらの値を設定するだけです

group = 'com.group' 
version = '1.0-SNAPSHOT'

コード

グラインダーを数回通した後、

myCustomPublicationName(MavenPublication)

カスタム設定の量が少ないほど良いと思います。デフォルトに便乗することを好みます...つまり、デフォルトを駆動する値を設定することを意味します... build.gradle .. myCustomPublicationName(MavenPublication) を設定しないでください

内部の値を変更する

myCustomPublicationName(MavenPublication)

デフォルトが機能しない場合に予約する必要があります（IMHO）。これは通常、非常に少数の時間です。

ノート：

non-root-gradle.build の上部にある「${name}」は、マルチモジュール プロジェクトのディレクトリ構造によって取り込まれています。

モノリスを書いたことがないので、非マルチモジュールでどのように機能するかわかりません。

私のコードのsettings.gradleの例：

rootProject.name = 'com.me.myproject-rootProjectName'

include ':source:java:mydatalayer'
include ':source:java:mybizlogic'
include ':source:java:mydomain'

以下のボーナス見積もり:

さらに、モジュール分解は、ソフトウェア品質の重要な要素です。密結合システムの場合、1 つのコンポーネントを微調整すると、システム全体が壊れます。API の観点から考えると、モジュール間の境界は明確であるため、他のモジュールに影響を与えることなく 1 つのモジュールを維持および改善できます。

大規模なリファクタリングは困難です。何かをモノリシック システムとして構築した後で、あちこちにコードが繰り返されていることに気付き、それを適切にリファクタリングしたい場合、膨大な作業が必要になります。対照的に、コンポーネントとして記述したものの、コンポーネントの境界の一部が少し間違っていた場合は、簡単に微調整できます。

-- Joshua Bloch 氏、Google の元チーフ Java アーキテクト。モジュール分解リンク

于 2020-09-27T07:14:40.343 に答える