Make Beam expansion service shadowJar multi-release

[Abacn]

so it processes multi-release dependencies correctly

Fix #33471

Please add a meaningful description for your change here

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[kennknowles]

This matches the fix I had to do in some other places. Did it work for this jar? Perhaps we should make it default somehow... I don't know if there is a downside.

[Abacn]

Yeah I think it's working. To test,

Creating a gradle project:

plugins {
    id 'java'
    id("com.github.johnrengelman.shadow") version "7.1.1"
}

repositories {
    mavenCentral()
    mavenLocal()
    maven {
        url 'https://repository.apache.org/content/groups/snapshots'
    }
}

dependencies {
    implementation("org.apache.beam:beam-sdks-java-io-expansion-service:2.63.0-SNAPSHOT")
}

def javaMainClass = "com.github.abacn.InspectClass"

task exec(type: Exec) {
    dependsOn build
    group = "Execution"
    description = "Run the main class with ExecTask"
    commandLine "java", "-classpath", sourceSets.main.runtimeClasspath.getAsPath(), javaMainClass
}

with a main class:

package com.github.abacn;

public class InspectClass {
  public static void main(String[] argv) throws ClassNotFoundException {
    String name = "org.xbill.DNS.spi.DnsjavaInetAddressResolverProvider";
    Class<?> clz = Class.forName(name);
    String path = clz.getProtectionDomain().getCodeSource().getLocation().getPath();
    System.out.println(name + ": " + path);
  }
}

---

Run with Java 21.

Before (run on nightly):

> Task :shadowPluginTest:exec FAILED
Exception in thread "main" java.lang.ClassNotFoundException: org.xbill.DNS.spi.DnsjavaInetAddressResolverProvider
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

After:

> Task :shadowPluginTest:exec
org.xbill.DNS.spi.DnsjavaInetAddressResolverProvider: /Users/yathu/.m2/repository/org/apache/beam/beam-sdks-java-io-expansion-service/2.63.0-SNAPSHOT/beam-sdks-java-io-expansion-service-2.63.0-SNAPSHOT.jar

[Abacn]

This matches the fix I had to do in some other places. Did it work for this jar? Perhaps we should make it default somehow... I don't know if there is a downside.

yeah I made it default to expansion services, where technically is run on different jre environment, and directly (without dependency resolution like maven or gradle)

Did a little search it seems multi-release jar is a debated, e.g. this blog https://blog.gradle.org/mrjars . So I ended up with only enabling it if upstream dependencies has used multi-released jar

imo the issue itself kind of indicated multi-release jar can bring problems.

[kennknowles]

This matches the fix I had to do in some other places. Did it work for this jar? Perhaps we should make it default somehow... I don't know if there is a downside.

yeah I made it default to expansion services, where technically is run on different jre environment, and directly (without dependency resolution like maven or gradle)

Did a little search it seems multi-release jar is a debated, e.g. this blog https://blog.gradle.org/mrjars . So I ended up with only enabling it if upstream dependencies has used multi-released jar

imo the issue itself kind of indicated multi-release jar can bring problems.

Good point. And thanks for the link to that article. It does seem like this could have the same impact on Beam users who build fat jars.