On the SparkRunner page, we advise users to download Beam sources and build 
JobService. So I think it would be better just to add a note there about this 
issue with old branches. 

> On 20 Jul 2020, at 22:29, Kenneth Knowles <k...@apache.org> 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>> 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>> wrote:
>> 
>> 
>> 
>> On Wed, Jul 8, 2020 at 12:07 PM Kyle Weaver <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>> 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>> 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>> 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 
>> > <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 
>> >> <https://issues.apache.org/jira/browse/BEAM-10263>
>> >> [2] https://github.com/apache/beam/pull/11527 
>> >> <https://github.com/apache/beam/pull/11527>
>> 
> 

Reply via email to