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.
Why is that? Don't we publish the Spark job server jar?
-Max
On 21.07.20 18:20, Alexey Romanenko wrote:
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
<mailto: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/
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) 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
