Thanks, I think I’ll update 2.20 and 2.21 then as latest release branches before it was fixed (in 2.22)
> On 21 Jul 2020, at 12:17, Maximilian Michels <m...@apache.org> wrote: > > We can't change releases, as they are voted and signed. > > +1 for updating the branches. That will give people the option to build > recent Beam versions. > > Note that it is not uncommon for source files to stop compiling. It's often > the case when build tools or the underlying platform change. Although > unfortunate, it is not in our interest to maintain old Beam versions, but > since fixing the mentioned issue is easy, it makes sense in this particular > instance. > > -Max > > On 20.07.20 22:29, Kenneth Knowles wrote: >> I think it is fine to fix it in branches. I do not see too much value in >> fixing it except in branches you know you are going to use. >> The "Downloads" page is for users and only mentioned the voted source >> releases, maven central, and pypi. There is nothing to do with GitHub or >> ongoing branches there. I don't think un-published cherrypicks to branches >> matter to users. Did you mean some other place? >> Kenn >> On Mon, Jul 20, 2020 at 9:44 AM Alexey Romanenko <aromanenko....@gmail.com >> <mailto:aromanenko....@gmail.com> <mailto:aromanenko....@gmail.com >> <mailto:aromanenko....@gmail.com>>> wrote: >> Then, would it be ok to fix it in branches (the question is how many >> branches we should fix?) with additional commit and mention that on >> “Downloads" page? >>> On 8 Jul 2020, at 21:24, Kenneth Knowles <k...@apache.org >>> <mailto:k...@apache.org> >>> <mailto:k...@apache.org <mailto:k...@apache.org>>> wrote: >>> >>> >>> >>> On Wed, Jul 8, 2020 at 12:07 PM Kyle Weaver <kcwea...@google.com >>> <mailto:kcwea...@google.com> >>> <mailto:kcwea...@google.com <mailto: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 <mailto:pabl...@google.com> >>> <mailto:pabl...@google.com <mailto: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 <mailto:aromanenko....@gmail.com> >>> <mailto:aromanenko....@gmail.com >>> <mailto: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/ >>> <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 <mailto:m...@apache.org> >>> <mailto:m...@apache.org <mailto: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
