Another reason to push on this is to get build times down. Once only generated proto classes use the shadow plugin we'll cut the build time in ~half? And there is no reason to constantly re-vendor.
Kenn On Fri, Oct 19, 2018 at 10:39 AM Kenneth Knowles <[email protected]> wrote: > Hi all, > > A while ago we had pretty good consensus that we should vendor > ("pre-shade") specific dependencies, and there's start on it here: > https://github.com/apache/beam/tree/master/vendor > > IntelliJ notes: > > - With shading, it is hard (impossible?) to step into dependency code in > IntelliJ's debugger, because the actual symbol at runtime does not match > what is in the external jars > - With vendoring, if the vendored dependencies are part of the project > then IntelliJ gets confused because it operates on source, not the produced > jars > > The second one has a quick fix for most cases*: don't make the vendored > dep a subproject, but just separately build and publish it. Since a > vendored dependency should change much more infrequently (or if we bake the > version into the name, ~never) this means we publish once and save headache > and build time forever. > > WDYT? Have I overlooked something? How about we set up vendored versions > of guava, protobuf, grpc, and publish them. We don't have to actually start > using them yet, and can do it incrementally. > > (side note: what do other projects like Flink do?) > > Kenn > > *for generated proto classes, they need to be altered after being > generated so shading happens there, but actually only relocation and the > shared vendored dep should work elsewhere in the project >
