Gradle module metadata not published for reactor-core 3.3.5

[janekbettinger]

Current Behavior:

reactor-core 3.3.5 was published with a Gradle module metadata declaration in its POM file (published-with-gradle-metadata), however, the corresponding .module file is missing in the Maven Central repository.

• https://search.maven.org/artifact/io.projectreactor/reactor-core/3.3.5.RELEASE/jar
• https://repo1.maven.org/maven2/io/projectreactor/reactor-core/3.3.5.RELEASE/reactor-core-3.3.5.RELEASE.pom

Expected Behavior:

1. reactor-core is published with Gradle module metadata and the .module file is published together with the POM and JAR file
2. or reactor-core is published without Gradle module metadata and does not declare it in the POM file

[janekbettinger]

This issue might be caused by the rather old Artifactory plugin:

reactor-core/build.gradle

Line 36 in a802238

id "com.jfrog.artifactory" version "4.9.8" apply false

The publication of Gradle metadata seems to be supported since version 4.11 only (jfrog/build-info#247 jfrog/build-info#265).

[simonbasle]

hi @kroka and thanks for reporting!

Can you give more details as to how to reproduce the issue, and whether or not it blocks you from depending on reactor at all? I tried to create a Gradle project that imports the BOM and depends on 3.3.5 as a result, both with Gradle 5.x and 6.x, and couldn't get it to complain about the missing deployed metadata.

Note that nonetheless it is a publication issue that we'll need to fix one way or another. I'm just wondering if it should trigger a release early than the next planned one, which is end of June.

[janekbettinger]

Hi,

for most users that retrieve the artifacts from Maven Central or JCenter the missing module file is no problem as they will get a HTTP status 404 for it and Gradle will simply ignore it. With Gradle 5 it's also no problem as it does not work with Gradle module metadata.

In our projects we use JFrog Artifactory (which kind of proxies the Maven Central repo) that, however, returns 401 instead of 404. While this can be considered as wrong behavior of the Artifactory, the root cause is the invalid POM file / missing module file.
Due to this we cannot build projects with reactor-core 3.3.5 (and thus cannot use the latest Spring Boot version 2.2.7). So this is really a blocking issue for us and, unfortunately, we have not found a good workaround, yet (like downgrading rsocket from Spring dependencies).

Issue in Artifactory:

• https://www.jfrog.com/jira/browse/RTFACT-13797
• https://www.jfrog.com/jira/browse/RTFACT-8765

Issue in Gradle

• Add a flag to treat 403 as a missing resource gradle/gradle#5606

We observed the invalid POM files in our projects, too, and solved it by updating the Artifactory plugin.
Alternatively, Gradle module metadata could be disabled like the guys from rsocket did in rsocket/rsocket-java#746 (motivated by spring-projects/spring-boot#20348). In the latter case the comment [...] <!-- do_not_remove: published-with-gradle-metadata --> disappears from the POM file and Gradle will not try do download a corresponding .module file.

I hope this helps understanding why this is an issue. It's a little thing but has an impact ;)

Best regards,
kroka

[simonbasle]

I think we'll amend the build to avoid generating module metadata. As far as I can see, it doesn't seem to easily support optional dependencies so 🤷

@bclozel @wilkinsona did you ever come across the case of optional dependencies and found a workaround ? I'm aware that you're moving away from publishing the module metadata too, but that it is due to the lack of support for exclusions

[simonbasle]

@kroka since it doesn't seem to affect users that fetch via bintray, the Spring artifactory or Maven Central (as these all give 404), we'll stick to the plan of releasing 3.3.6 in June for now.

one workaround I can think about is to checkout the project locally and generate the module metadata:

git checkout v3.3.5.RELEASE
./gradlew publishToMavenLocal -x check
cd ~/.m2/repository/io/projectreactor/reactor-core/3.3.5.RELEASE

Then you should technically be able to add the reactor-core-3.3.5.RELEASE.module file to the company's Artifactory, as it allows manually adding files to a given folder IIRC.

The drawback would be that for 3.3.5 you'd inherit strong dependencies instead of optional ones:

        {
          "group": "com.google.code.findbugs",
          "module": "jsr305",
          "version": {
            "requires": "3.0.2"
          }
        },
        {
          "group": "org.slf4j",
          "module": "slf4j-api",
          "version": {
            "requires": "1.7.12"
          }
        },
        {
          "group": "io.micrometer",
          "module": "micrometer-core",
          "version": {
            "requires": "1.3.0"
          }
        },
        {
          "group": "org.jetbrains.kotlin",
          "module": "kotlin-stdlib",
          "version": {
            "requires": "1.3.71"
          }
        },
        {
          "group": "io.projectreactor.tools",
          "module": "blockhound",
          "version": {
            "requires": "1.0.3.RELEASE"
          }
        }

[wilkinsona]

@simonbasle What's the problem with optional dependencies? We're publishing Gradle module metadata for spring-boot-autoconfigure which has numerous optional dependencies without any problems. The exclusions limitation only affects a single module in Spring Boot (spring-boot-dependencies) so we'll stop publishing the metadata for that one module, but carry on publishing it for all the others.

[simonbasle]

@wilkinsona from what I can see when doing a publishToMavenLocal with Gradle 6.3 in reactor, the generated .module lists the versions as above. All these versions in my previous comment are <optional>true</optional> in the pom.xml.

But of course, that is the result of a customization in a withXml() block...
That is done by iterating through the dependencies listed under the optional configuration provided IIRC by propdeps plugin ('org.springframework.build.gradle:propdeps-plugin:0.0.7').

And so, when I try to create a Gradle project that depends on these artifacts with the generated .module in the local maven repo, I get the whole bunch of transitive dependencies. If I remove the .module then I don't get the transitive dependencies.

Is that not the case with Spring Boot ?

[wilkinsona]

Ah, the propdeps plugin. We don't use it in Boot for a few reasons, this being one of them. We have our own OptionalDependenciesPlugin that we use instead. Framework has a copy of it too. It's starting to feel like we should extract it into a spring-gradle-plugins project so it can be shared without copy-paste.

[janekbettinger]

@simonbasle thank you for the comprehensive feedback! I agree and think that there is no need for an earlier release given that not all users are affected and that the issue we have is rather caused by multiple aspects.

[santoshkumarcts]

@kroka facing the same issue, any work around ?

[janekbettinger]

@santoshkumarcts we do not have a good workaround, but I haven't spent too much time on it (had some struggle with permissions for pushing to the company's Artifactory from my local machine). Right now we stick with Spring Boot 2.2.4 and Spring Cloud Hoxton SR2. A downgrade to Gradle 5.6 should do the job, too, if it does not break your Gradle scripts.

[janekbettinger]

@santoshkumarcts this seems to work:

implementation platform("org.springframework.boot:spring-boot-dependencies:${springBootVersion}")
implementation platform("org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}")

// work around https://github.com/reactor/reactor-core/issues/2151
implementation('io.projectreactor:reactor-core:3.3.4.RELEASE') {
        force = true
}

with Spring Boot 2.3.0.RELEASE and Spring Cloud Hoxton.SR2 (due to rsocket/rsocket-java#746 downgrading to RC5 did not work on first trial).

If you use the Gradle Spring Dependency Management plugin you'll probably have to set the reactor version by a property: https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/reference/htmlsingle/#dependency-versions-properties