If it continues to occur, maybe it is an environmental issue, be sure to try to clean as well. ./gradlew clean
On Mon, Jan 28, 2019 at 11:12 AM Ryan Williams <r...@runsascoded.com> wrote: > Yea I was rebased on top of a more recent master than your previous > message, when I saw it again. Perhaps I was mistaken. I'll ping here if I > see it again, thanks. > > On Mon, Jan 28, 2019 at 1:52 PM Alex Amato <ajam...@google.com> wrote: > >> After I did a rebase, it went away for me. So I think that this should >> work. Are you saying that you did rebase ontop of master and it still >> occurred? Strange. >> >> On Sat, Jan 26, 2019 at 3:48 PM Ryan Williams <r...@runsascoded.com> >> wrote: >> >>> Hm, I just encountered this again on a branch that based on 5b46b02b49 >>> (top of trunk from this afternoon). Is it definitely supposed to be fixed? >>> >>> >>> On Thu, Jan 24, 2019 at 9:19 PM Alex Amato <ajam...@google.com> wrote: >>> >>>> Please try rebasing from master, I believe this issue has been resolved. >>>> >>>> On Thu, Jan 24, 2019 at 3:29 PM Ryan Williams <r...@runsascoded.com> >>>> wrote: >>>> >>>>> I'm seeing every ≈third `./gradlew compileJava` fail locally due to >>>>> this; re-running the commit has always succeeded, so far. >>>>> >>>>> Sounds like there is not an immediate fix in the works / no one >>>>> assigned on the JIRA? >>>>> >>>>> On Wed, Jan 23, 2019 at 3:17 PM Kenneth Knowles <k...@apache.org> >>>>> wrote: >>>>> >>>>>> This might connect to vendoring Calcite. It will be easiest, and have >>>>>> the best incremental build, if we separate the generated code into its >>>>>> own >>>>>> module that has relocation to match the vendored Calcite. >>>>>> >>>>>> Kenn >>>>>> >>>>>> On Wed, Jan 23, 2019 at 11:29 AM Anton Kedin <ke...@google.com> >>>>>> wrote: >>>>>> >>>>>>> We don't pre-generate the code as a separate step. Code gen from the >>>>>>> SQL parser syntax spec and its compilation happens both during the Beam >>>>>>> SQL >>>>>>> build task. Splitting the code generation and compilation might not be >>>>>>> trivial. We definitely should look into fixing this though. >>>>>>> >>>>>>> Regards, >>>>>>> Anton >>>>>>> >>>>>>> On Wed, Jan 23, 2019 at 11:13 AM Alex Amato <ajam...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Okay, make sense perhaps we can somehow make it fail when it fails >>>>>>>> to generate the dep, rather than when compiling the java code later on >>>>>>>> >>>>>>>> On Wed, Jan 23, 2019 at 11:12 AM Anton Kedin <ke...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> ParserImpl is autogenerated by Calcite at build time. It seems >>>>>>>>> that there's a race condition there and it sometimes fails. Rerunning >>>>>>>>> the >>>>>>>>> build works for me. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Anton >>>>>>>>> >>>>>>>>> On Wed, Jan 23, 2019, 11:06 AM Alex Amato <ajam...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> https://jira.apache.org/jira/browse/BEAM-6495?filter=-2 >>>>>>>>>> >>>>>>>>>> Any ideas, how this got through the precommit? >>>>>>>>>> >>>>>>>>>> > Task :beam-sdks-java-extensions-sql:compileJava FAILED >>>>>>>>>> >>>>>>>>>> /usr/local/google/home/ajamato/go/src/ >>>>>>>>>> github.com/apache/beam/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/JdbcFactory.java:29: >>>>>>>>>> error: cannot find symbol >>>>>>>>>> >>>>>>>>>> import >>>>>>>>>> org.apache.beam.sdk.extensions.sql.impl.parser.impl.BeamSqlParserImpl; >>>>>>>>>> >>>>>>>>>> ^ >>>>>>>>>> >>>>>>>>>> symbol: class BeamSqlParserImpl >>>>>>>>>> >>>>>>>>>> location: package >>>>>>>>>> org.apache.beam.sdk.extensions.sql.impl.parser.impl >>>>>>>>>> >>>>>>>>>> 1 error >>>>>>>>>> >>>>>>>>>>
