【问题标题】:How do I generate maven-metata.xml with maven-publish and the artifactory-gradle-plugin?如何使用 maven-publish 和 artifactory-gradle-plugin 生成 maven-metata.xml?
【发布时间】:2015-05-03 12:25:24
【问题描述】:

我在 groovy 中编写了一个 Gradle 插件并使用 Gradle 构建它。我有一个本地网络 Artifactory 服务器,我使用 Gradle Artifactory 插件和 Gradle 中的 maven-publish 插件发布结果。我有另一个 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 中自动生成它的东西。我不想手动更新文件,因为这会破坏自动化工作,我不想切换到 mvn,因为我已经在 Gradle 上投入了很多。

【问题讨论】:

    标签: maven gradle artifactory maven-metadata


    【解决方案1】:

    groupId 必须添加到 publications 部分。实施后,maven-metadata.xml 文件将发布到工件存储库。

    publishing {
        publications {
            mavenJava(MavenPublication) {
                groupId = 'com.group'
            }
        }
    }
    

    【讨论】:

      【解决方案2】:

      我遇到了同样的问题,结果发现 Artifactory 存储库不是 Maven 存储库,而是通用存储库。我花了很长时间才注意到,因为我没有创建存储库,并且我认为它是一个 Maven 存储库,否则部署/解析工作正常。
      切换到 Maven 存储库后,发布时会生成 maven-metadata.xml。

      【讨论】:

        【解决方案3】:

        maven-metadata.xml 应该由 Artifactory 处理。 您在 Artifactory 中的本地存储库布局是什么?

        【讨论】:

        • 这是 plugins-release-local 和 plugins-snapshot-local 的默认布局,它是 maven-2-default。我还应该提到它是 Artifactory 的开源版本,所以我实际上认为它可能是一个需要 Pro 或更高版本的功能。
        • 好吧,开枪。我提到的第二个项目收到了一个 maven-metadata.xml 文件。我将尝试使用 groupId 的第一个,看看是否会有所不同。
        • 果然添加了groupId导致Artifactory生成了一个maven-metadata.xml文件。
        • 我不同意。构建工具需要检查存储库中是否已存在 maven-metadata.xml。如果它存在,它需要下载它并用新信息更新它,但要附加到它上面。如果它不存在,那么它需要生成一个新的。为您生成此文件的不是工件存储库管理器。当然,如果有计划任务,它可以做到这一点,但实际上必须由构建和部署工具来处理。
        【解决方案4】:

        接受的答案是正确的。我投了赞成票。但是,也有这个警告。

        我有一个多模块项目,所以我将使用“allprojects”。如果您有一个整体/单一 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)(但 root 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)

        应该保留(恕我直言)当默认设置不适合您时。这通常是极少数的时间。

        注意:

        “${name}”位于我的非根目录顶部的 gradle.build 正在由我的多模块项目的目录结构填充。

        我不知道它在非多模块中是如何工作的,因为我从不编写单体。

        我的代码中的settings.gradle 示例:

        rootProject.name = 'com.me.myproject-rootProjectName'
        
        include ':source:java:mydatalayer'
        include ':source:java:mybizlogic'
        include ':source:java:mydomain'
        

        以下奖励报价:

        此外,模块化分解是软件的关键组成部分 质量。如果你有一个紧密耦合的系统,当你调整一个 组件,整个系统崩溃。如果您从 API 的角度考虑, 模块间界限清晰,因此您可以维护和改进 一个模块而不影响其他模块。

        大规模重构被证明是困难的。如果你建造一些东西作为 单体系统,然后发现你在整个系统中都有重复的代码 地方,并且你想正确地重构它,你将拥有一个巨大的 工作。相反,如果你把它写成组件,但你得到了一些 组件边界有点错误,您可以轻松调整它们。

        -- 谷歌前首席 Java 架构师 Joshua Bloch。模块化分解链接

        【讨论】:

          猜你喜欢
          • 2016-04-04
          • 2015-07-30
          • 2021-05-15
          • 1970-01-01
          • 1970-01-01
          • 2011-12-30
          • 2023-03-04
          • 2018-07-06
          • 1970-01-01
          相关资源
          最近更新 更多