On Wed, Jul 8, 2020 at 12:07 PM Kyle Weaver <kcwea...@google.com> wrote:
> > To fix on previous release branches, we would need to make a new > release, is it not? Since hashes would change.. > > Would it be alright to patch the release branches on Github and leave the > released source as-is? Github release branches themselves aren't release > artifacts, so I think it should be okay to patch them without making a new > release. > Yea. There are tags for the exact hashes that RCs were built from. The release branch is fine to get new commits, and then if anyone wants to build a patch release they will get those commits. Kenn > On Wed, Jul 8, 2020 at 11:59 AM Pablo Estrada <pabl...@google.com> wrote: > >> Ah that's annoying that a dependency would be removed from maven. I >> thought that was not meant to happen? This must be an issue happening for >> many other projects... >> Why is errorprone a dependency anyway? >> >> To fix on previous release branches, we would need to make a new release, >> is it not? Since hashes would change.. >> >> On Wed, Jul 8, 2020 at 10:21 AM Alexey Romanenko < >> aromanenko....@gmail.com> wrote: >> >>> Hi Max, >>> >>> I’m +1 for back porting as well but that seems quite complicated since >>> we distribute release source code from https://archive.apache.org/ >>> Perhaps, we should just warn users about this issue and how to >>> workaround it. >>> >>> Any other ideas? >>> >>> > On 8 Jul 2020, at 11:46, Maximilian Michels <m...@apache.org> wrote: >>> > >>> > Hi Alexey, >>> > >>> > I also came across this issue when building a custom Beam version. I >>> applied the same fix (https://github.com/apache/beam/pull/11527) which >>> you have mentioned. >>> > >>> > It appears that the Maven dependencies changed or are no longer >>> available which causes the missing class files. >>> > >>> > +1 for backporting the fix to the release branches. >>> > >>> > Cheers, >>> > Max >>> > >>> > On 08.07.20 11:36, Alexey Romanenko wrote: >>> >> Hello, >>> >> Some days ago I noticed that I can’t build the project from old >>> release branches . For example, I wanted to build and run Spark Job Server >>> from “release-2.20.0” branch and it failed: >>> >> ./gradlew :runners:spark:job-server:runShadow —stacktrace >>> >> * Exception is: >>> >> org.gradle.api.tasks.TaskExecutionException: Execution failed for >>> task ':model:pipeline:compileJava’. >>> >> … >>> >> Caused by: org.gradle.internal.UncheckedException: >>> java.lang.ClassNotFoundException: >>> com.google.errorprone.ErrorProneCompiler$Builder >>> >> … >>> >> I experienced the same issue for “release-2.19.0” and >>> “release-2.21.0” branches, I didn’t check older branches but seems it’s a >>> global issue for “net.ltgt.gradle:gradle-errorprone-plugin:0.0.13". >>> >> This is already known issue and it was fixed for 2.22.0 [1] a while >>> ago. By applying a fix from [2] on top of previous branch, for example, >>> “release-2.20.0” branch I’ve managed to build it. Though, the problem for >>> old branches (<2.22.0) is still there - it’s not possible to build them >>> right after checkout without applying the fix. >>> >> So, there are two questions: >>> >> 1. Is anyone aware why the old static version of >>> gradle-errorprone-plugin fails for the branches that were successfully >>> built before? >>> >> 2. Do we have to fix it for release branches <2.22.0 (either >>> cherry-pick the fix for 2.22.0 or somehow else if it’s possible)? >>> >> [1] https://issues.apache.org/jira/browse/BEAM-10263 >>> >> [2] https://github.com/apache/beam/pull/11527 >>> >>>
