Remove antlr from dependency from java-core pom

[Abacn]

Alternative fix of #32696

We already vendored and repackaged antlr runtime into the jar. It was intended to avoid dependency version conflict if user using different antlr versions. However, beam java core still declares it as a dependency.

Before:

java core pom has antlr4-runtime dependency, e.g. in https://repo1.maven.org/maven2/org/apache/beam/beam-sdks-java-core/2.60.0/beam-sdks-java-core-2.60.0.pom

<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4-runtime</artifactId>
<version>4.7</version>
<scope>compile</scope>

after:

ran ./gradlew :sdks:java:core:publishToMavenLocal -Ppublishing and checked that antlr-runtime is no longer a dependency of beam java core in generated pom.

Also checked the jar still repackaged antlr runtime in org/apache/beam/repackaged/core/org/antlr/v4/runtime

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.

[pinfrederic]

I think that solution is even better than the previous one.
I guess this time we can use a different version in our pipelines if we need it... can you confirm?
With this solution do we still have a risk of having conflicts with beam at runtime?

[Abacn]

Thanks for the feedback.

I guess this time we can use a different version in our pipelines if we need it... can you confirm?

Yes. I think with current version user can still use a different version, but they need to pin the dependency like #32696 (comment)

The problem on the current HEAD is that beam core "leaks" the antlr-runtime dependency while it was supposed to be shaded

do we still have a risk of having conflicts with beam at runtime?

Yes that is what I understood.

[Abacn]

R: @shunping

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment assign set of reviewers

[pinfrederic]

#Yes. I think with current version user can still use a different version, but they need to pin the dependency like #32696 (comment)

Can you set the dependency as "compile only" in the gradle file? This would avoid us to do this
exclude group: 'org.antlr', module: '*'

[Abacn]

#Yes. I think with current version user can still use a different version, but they need to pin the dependency like #32696 (comment)

Can you set the dependency as "compile only" in the gradle file? This would avoid us to do this exclude group: 'org.antlr', module: '*'

After this change antlr will be a "compile only" dependency (more precisely its a custom gradle config, used for generating java code from antlr source), won't leak into the pom.

do we still have a risk of having conflicts with beam at runtime?

Yes that is what I understood.

I mean there could be other Beam's dependency, not Beam itself, having transient antlr dependency, that could be conflict with user dependency. This is based on the observation of #33016 #14787 - bumping antlr version then some tests breaks elsewhere.

[pinfrederic]

Alright, understood. Thanks

[Abacn]

many tests failing in ':runners:direct-java:needsRunnerTests' target due to

java.lang.NoClassDefFoundError: org/antlr/v4/runtime/CharStream
	at org.apache.beam.sdk.schemas.FieldAccessDescriptor.withFieldNames(FieldAccessDescriptor.java:187)
	at org.apache.beam.sdk.schemas.FieldAccessDescriptor.withFieldNames(FieldAccessDescriptor.java:174)

checked that the same test, if running under ':runners:direct-java:test', will pass.

The reason it failed is because the tests running on unshaded compiled class (haven't redirect antlr yet)

I see, I found the cause:

the test is using

beam/runners/direct-java/build/libs/beam-runners-direct-java-2.61.0-SNAPSHOT.jar!/org/apache/beam/sdk/schemas/...

but the shaded direct java jar does not have antlr redirected.

[Abacn]

R: @shunping

[Abacn]

Java PreCommit failing tests are FanOutStreamingEngineWorkerHarnessTest, also flaky on master branch: #32775 (comment) not related to this PR

[pinfrederic]

Question: Do you build a docker image from the master branch after each PR merged? This would help me to try this change before the v2.61 to be released