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>> 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
