Ismaël and I think the short-term solution for Aaron's issue is to define Beam's own class for Avro's TimestampConversion. Luckily it's the only blocker for Avro 1.9 I found. I created a ticket https://issues.apache.org/jira/browse/BEAM-9144 and PR https://github.com/apache/beam/pull/10628 .
Regards, Tomo On Fri, Jan 17, 2020 at 7:32 AM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > > On Thu, Jan 16, 2020 at 7:08 PM Kenneth Knowles <k...@apache.org> wrote: > > > > Regarding Google's advice about shading: don't go to a "one version rule" > > monorepo for advice about solving diamond dependencies in the wild. > > FWIW these docs came out of the open source, Github, multirepo, many > versions part of Google Cloud, not the mono repo world of google3. > Though I will say the more time I spend trying to deal with these > issues the more I love the monorepo. > > > It is a useful description of the pitfalls. We (and Flink before us, and > > likely many more) are already doing something that avoids many of them or > > makes them less likely. Building a separate vendored library is simpler and > > more robust than the "shade during build". > > > > I've only encountered "vendoring" as distinct from shading in Beam. > Are there more details about this anywhere? A quick Google search only > turned up one Beam doc that pointed to Go docs and a cloud endpoints > doc that seemed to use it as a synonym for shading. > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Regards, Tomo
