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